早在2018年，Chrome就默认开启了站点隔离功能，以缓解UXSS、Spectre等漏洞的影响。当时，我积极参与Chrome漏洞赏金计划，并因发现站点隔离机制中的10多个漏洞而获得32,000美元的奖励。在本系列文章中，我们不仅会为读者讲解站点隔离的运行机制和相关的安全功能，还会介绍在该安全机制中发现的安全漏洞。当然，目前这些漏洞已经被修复。挖洞方法当我在Chrome中挖掘安全漏洞时，我通常从手动测试开始，而不是先进行代码审查，因为Chrome团队更擅长代码审查。所以我认为通过代码审查漏掉的任何逻辑错误通常很难通过代码审计找到。因此，当我开始进行站点隔离时，我采用了相同的方法。什么是站点隔离？站点隔离是一种安全功能，可将每个站点的网页隔离到单独的进程中。通过站点隔离机制，站点的隔离与操作系统层面的进程隔离一致，而不是通过同源策略实现进程内部的逻辑隔离。此处，Site定义为Scheme和eTLD+1（也称为Schemefulsame-site）。https://www.microsoft.com:443/因此，Site的定义比Origin广，Origin由Scheme、Host和Port定义。https://www.microsoft.com:443/但是，并非所有情况都符合上述Site的定义。所以我开始测试下面的边缘案例，看看站点隔离在每种情况下的表现如何。不带域名的URL实际上，URL不需要包含域名（例如IP地址）。在这种情况下，站点隔离又回到了进程隔离的同源比较。文件URL本地文件可以通过文件方案呈现到浏览器选项卡中。目前，站点隔离将使用文件方案的所有URL视为源自同一站点。数据URL虽然在顶部框架上加载的数据URL始终与它自己的进程保持隔离，但在iframe内加载的数据URL将从导航发起者那里继承站点（尽管来源仍然是不透明的来源）。老读者可能还记得一个类似的概念，iFrame中的DataURL使用了从Firefox继承的源。正如您在上图中所见，即使这两个示例都导致Microsoft.com嵌入数据URLiframe，跨站点情况仍然使进程保持隔离，因为导航的发起者是evil.example。数据URL站点继承中的漏洞如果浏览器或选项卡从本地缓存中恢复，会发生什么情况？此时，站点隔离机制还会记住DataURL导航的始作俑者吗？原来，恢复浏览器或选项卡后，SiteIsolation记不住导航发起者。从本地缓存恢复选项卡时，站点隔离通常会盲目地将数据URL放置在与父框架相同的站点中。攻击者可以触发浏览器崩溃然后恢复浏览器，从而绕过站点隔离。从本地缓存恢复页面时，您可以通过将数据URL隔离到另一个进程来解决这个问题。来源不透明的BlobURL当从来源不透明（例如数据URL、沙盒iframe或文件URL）创建BlobURL时，BlobURL将采用“blob:null/[GUID]”形式。由于这是一个没有域名的URL，站点隔离机制会退化为同源比较。但是，这是一个漏洞，因为攻击者可以通过其他站点创建来源不透明的blobURL。而且同源比较还不够，因为源总是“blob:null”。所以URL需要同时比较来源和路径进行进程隔离。测试进程隔离逻辑借助ChromiumTaskManager（在Windows中可以通过Shift+Esc组合键调出）和FramesExplorer等工具，我们发现站点隔离机制的进程隔离逻辑存在一些问题，有助于：确定哪些框架共享相同的进程（或者，您可以使用chrome://process-internals/#web-contents来完成相同的事情）。站点隔离如何减轻UXSS攻击？从历史上看，大多数UXSS攻击都是通过绕过渲染器进程中实施的同源策略检查来实现的。换句话说，一旦您可以绕过同源策略检查，所有跨站点数据都可以在渲染器进程中使用。因此，JS代码能够获取窗口、文档或任何其他跨域对象引用。站点隔离通过隔离进程从根本上改变了这一点。也就是说，即使你可以绕过同源策略检查，其他站点的数据也不能在同一个进程中使用。此外，UXSS将跨源窗口导航到JavaScriptURL的方法也不是问题。我们知道，要使JavaScriptURL导航成功，两个网页必须具有相同的来源。因此，可以在呈现器进程中处理到JavaScriptURL的导航（呈现器应该托管任何具有窗口引用的同源网页），这样就可以安全地忽略上传到浏览器进程的任何JavaScriptURL导航请求。当然，如果您忘记在浏览器进程中忽略JavaScriptURL，那将是一个错误。仅进程隔离是不够的站点隔离有助于缓解UXSS，但进程隔离不足以防止所有跨站点数据泄漏。最简单的例子就是Spectre攻击。通过Spectre攻击，攻击者可以读取进程的整个地址空间。虽然进程隔离有助于隔离网页，但子资源（如图片、音频、视频等）并不是进程隔离的。因此，在没有其他缓解措施的情况下，攻击者可以通过在页面中嵌入img标签来读取任意跨站点页面。Cross-OriginReadBlockingCross-OriginReadBlocking(CORB)通过检查跨源子资源中响应的MIME类型来降低暴露敏感跨源数据的风险。如果跨源子资源的MIME类型在拒绝列表中（例如HTML、XML、JSON等），默认情况下不会将响应发送到渲染器进程，因此无法使用Spectre攻击读取.绕过CORB目前，有几种方法可以绕过CORB。CORBbypassinWorkersby@_tsuroCORBbypassinWebSocketby@piochuCORBbypassinAppCache从根本上说，如果使用URLLoader来获取禁用了CORB的URL，并且响应被泄露到跨站点Web渲染服务器进程，则可以绕过CORB.例如，我们能够使用AppCache绕过CORB，因为用于下载缓存资源的URLLoader禁用了CORB。据我所知，AppCache曾经允许缓存跨源HTML文件，因此，我认为这可能会导致CORB被绕过，它确实做到了。另请注意，某些渲染器进程可以通过某些设计（例如扩展渲染器进程）绕过CORB。跨源资源策略虽然CORB默认保护许多敏感资源，但某些资源（例如图像）可以嵌入到Web上的多个站点中。因此，CORB默认情况下无法将此类资源保护到跨域页面中。跨源资源策略(CORP)允许开发人员决定是否可以将某些资源嵌入到同源、同站点或跨源页面中。浏览器可以利用这些规定来保护默认情况下CORB无法保护的资源。使用CORP，网站可以保护敏感资源免受各种攻击，例如Spectre攻击、XSSI、子资源特定的SOP绕过等。换句话说，可以使用Spectre攻击读取缺少CORP标头的敏感资源（除非资源受到保护由CORB）。如何测试CORB如果您想尝试绕过CORB加载子资源的想法（例如，通过上面的AppCache），请尝试使用以下响应标头加载该子资源：Content-Type:text/htmlX-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/如有转载请注明出处。
