早在2018年，Chrome就默认启用了站点隔离功能，以缓解UXSS和Spectre等漏洞带来的影响。当时，我积极参加了Chrome漏洞奖励计划，并在站点隔离机制中发现了10多个漏洞，从而获得了3.2万美元的奖励。

在本系列文章中，我们不仅会为读者解释站点隔离和相关安全功能的运行机制，同时，还会介绍在该安全机制发现的安全漏洞，当然，目前这些漏洞已经得到了修复。

挖洞方法

当我在Chrome中挖掘安全漏洞的时候，通常会从手动测试开始下手，而不是先进行代码审查，因为Chrome团队更擅长代码审查。所以我认为，但凡从他们的代码审查中漏网逻辑漏洞，通常都很难通过代码审计找到。因此，当我开始研究站点隔离时，我遵循了相同的方法。

什么是站点隔离？

站点隔离是一种安全功能，它将每个站点的网页隔离到单独的进程中。通过站点隔离机制，站点的隔离与操作系统级别的进程隔离保持一致，而不是通过同源策略等在进程内实现逻辑隔离。

在这里，Site定义为Scheme和eTLD+1（也称为Schemeful same-site）。

https://www.microsoft.com:443/

因此，Site的定义比Origin更宽泛，Origin是通过Scheme、Host和Port来进行定义的。

https://www.microsoft.com:443/

然而，并不是所有的情况都符合上述Site的定义。因此，我开始测试下面的边缘情况，看看站点隔离在每种情况下的表现如何。

不含域名的URL

实际上，URL并不需要包含域名（例如IP地址）。在这种情况下，站点隔离就变回了同源比较，以实现进程隔离。

File URL

本地文件可以通过文件scheme呈现到浏览器选项卡中。目前，站点隔离将使用文件scheme的所有URL都视为源自同一站点。

Data URL

虽然加载在顶部frame上的Data URL始终与它自己的进程保持隔离，但加载在iframe内的Data URL将从导航发起方那里继承Site（尽管源仍然是opaque origin）。年龄较大的读者可能会记得类似的概念，iFrame中的Data URL使用的是继承自Firefox的源。

正如您在上面的图像中所看到的，即使两个示例都导致Microsoft.com嵌入数据URL iframe，但是跨站点的情况仍然是保持进程隔离的，因为导航发起方是evil.example。

Data URL站点继承中的漏洞

如果从本地缓存还原浏览器或选项卡，那么会发生什么情况？这时，站点隔离机制还会记得Data URL的导航发起方吗？

事实证明，还原浏览器或选项卡后，站点隔离无法记住导航启动方。从本地缓存还原选项卡时，站点隔离通常会盲目地将Data URL放在父frame的同一站点内。攻击者可以触发浏览器崩溃，然后还原浏览器，从而绕过站点隔离机制。

从本地缓存还原页面时，可以通过将Data URL隔离到另一个进程中来解决这个问题。

具有不透明源的Blob URL

从不透明的源（opaque origin）创建Blob URL（例如Data URL、沙箱iframe或File URL）时，Blob URL将采用“blob:null/[GUID]”这样的形式。

由于这是一个没有域名的URL，因此，站点隔离机制将退化为同源比较。但是，这是一个漏洞，因为攻击者可以通过其他站点创建具有不透明源的Blob URL。而且同源比较还远远不够，因为源始终是“blob:null”。因此，该URL需要同时对源和路径进行比较，以进行进程隔离。

测试进程隔离逻辑

借助于Chromium任务管理器（Windows中可以通过Shift + Esc组合键调出它）和FramesExplorer等工具，我们在站点隔离机制的进程隔离逻辑中发现了一些问题，这有助于识别哪些frame共享了同一个进程（此外，您还可以使用chrome://process-internals/#web-contents来完成同一任务）。

站点隔离如何缓解UXSS攻击？

从历史上看，大多数UXSS攻击都是通过绕过在渲染器进程中实现的同源策略检查来实现的。换句话说，一旦您可以绕过同源策略检查，所有跨站点数据就都可以在渲染器进程中使用。因此，JS代码能够获取窗口、文档或任何其他跨域对象引用。

站点隔离通过隔离进程从根本上改变了这一点。也就是说，即使您可以绕过同源策略检查，其他站点的数据也无法在同一进程中使用。

此外，将跨域窗口导航到JavaScript URL的UXSS手段也不是问题。我们知道，JavaScript URL导航要想成功，2个网页必须是同源的。因此，对JavaScript URL的导航可以在渲染器进程内处理（渲染器应该承载任何具有窗口引用的同源网页），这样，任何上传到浏览器进程的JavaScript URL导航请求都可以安全地被忽略。当然，如果您忘记了在浏览器进程中忽略JavaScript URL，那就是一个bug了。

只有进程隔离还远远不够

站点隔离有助于缓解UXSS，但是进程隔离还不足以防止所有跨站点数据泄漏。

最简单的例子就是Spectre攻击。借助Spectre攻击，攻击者可以读取进程的整个地址空间。尽管进程隔离有助于隔离网页，但子资源（例如图像、音频、视频等）不是进程隔离的。

因此，在没有其他缓解措施的情况下，攻击者可以通过使用img标签嵌入该页面来读取任意跨站点页面。 

跨源读取阻止

跨源读取阻止（Cross-Origin Read Blocking，CORB）通过检查跨源子资源中响应的MIME类型来减轻暴露敏感的跨域数据的风险。如果跨源子资源的MIME类型在拒绝列表中（例如HTML、XML、JSON等），则默认情况下不会将响应发送到渲染器进程，因此，使用Spectre攻击将无法读取该响应 。

绕过CORB

目前，已经有多种方法可以绕过CORB。

·  CORB bypass in Workers by @_tsuro

· CORB bypass in WebSocket by @piochu

· CORB bypass in AppCache

从根本上说，如果使用URLLoader在禁用CORB的情况下获取了URL，并且响应被泄露给了跨站点的Web渲染器进程，那么就可以绕过CORB。

例如，我们能够使用AppCache来绕过CORB，因为用于下载缓存资源的URLLoader禁用了CORB。据我所知，AppCache曾经允许缓存跨源的HTML文件，所以，我想这可能会导致CORB被绕过，而且事实也确实如此。

同样需要注意的是，一些渲染器进程可以通过某些设计（例如扩展渲染器进程）来绕过CORB。

跨源资源策略

虽然CORB默认情况下可以保护很多敏感资源，但有些资源（如图片）可以嵌入Web上的多个站点中。因此，CORB默认情况下不能保护此类资源进入跨源页面。

跨源资源策略(CORP)允许开发人员规定某些资源是否可以嵌入到同源、同站点或跨源页面。浏览器可以利用这些规定来保护那些默认情况下无法受到CORB保护的资源。

通过CORP，网站可以保护敏感资源免受各种攻击，如Spectre攻击、XSSI、特定于子资源的SOP绕过等。换句话说，缺少CORP头部的敏感资源可以使用Spectre攻击来读取（除非资源受到CORB的保护）。

如何测试CORB

如果您想试验绕过CORB加载子资源（例如，通过上面的AppCache绕过CORB）的想法，请尝试使用以下响应头部来加载该子资源：

Content-Type: text/html
X-Content-Type-Options: nosniff

正常情况下，CORB应该阻止此类跨域子资源，因此，如果正确加载了子资源，则表明存在CORB绕过漏洞。

如果您想知道在哪些地方不能加载子资源（例如，通过上面的WebSocket绕过CORB），请使用windbgs!address命令，通过在堆中搜索目标字符串，以确认它们是否已经进入渲染器进程。

!address /f:Heap /c:"s -a %1 %2 \"secret\""

这将在渲染器进程的堆内存中搜索字符串secret。如果要查找unicode字符串而非ascii字符串，则可以将-a更改为-u。

小结

借助站点隔离、CORB和CORP保护机制，不仅可以缓解从UXSS到Spectre等诸多攻击，同时，还能缓解允许攻击者读取跨站点信息的其他客户端漏洞带来的危害。但是，有些攻击可能会危及渲染器进程。在下一篇文章中，我们将集中讨论如何进一步加强站点隔离机制，以降低攻击者通过这种漏洞获取跨站点信息的风险。

本文翻译自：https://microsoftedge.github.io/edgevr/posts/deep-dive-into-site-isolation-part-1/如若转载，请注明原文地址：