早在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导航要想成功，两个网页必须是同源的。因此，是的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)请尝试使用以下响应头来加载子资源：
正常情况下，CORB因此，如果子资源被正确加载，则应防止此类跨域子资源的存在CORB绕过漏洞。
如果你想知道子资源不能在哪里加载(例如，通过上述)WebSocket绕过CORB)，请使用windbgs!address通过在堆中搜索目标字符串，命令确认它们是否已进入渲染器过程。
这将在渲染器过程中的堆内存中搜索字符串secret。如果要查找unicode字符串而非ascii字符串，可以-a更改为-u。
小结
借助网站隔离，CORB和CORP保护机制不仅可以缓解UXSS到Spectre同时，它还可以减轻允许攻击者阅读跨站点信息的其他客户端漏洞的危害。然而，一些攻击可能会危及渲染过程。在下一篇文章中，我们将重点讨论如何进一步加强网站隔离机制，以降低攻击者通过这个漏洞获取跨网站信息的风险。
本文翻译自：https://microsoftedge.github.io/edgevr/posts/deep-dive-into-site-isolation-part-1/如果转载，请注明原始地址。