接上篇文章《深度剖析站点隔离机制，Part 1》在上一篇文章中，我们向读者讲解了站点隔离及相关安全机制如何缓解UXSS、Spectre等黑客攻击的。然而，由于渲染器进程中的安全漏洞非常普遍，Chromium的威胁模型假设渲染器进程可以被破坏，也就是说，它是不可信任的。为了与这种威胁模型保持一致，Chromium在2019年宣布对站点隔离机制进行相应的改进，以进一步减轻受损渲染器进程可能造成的危害。在这篇文章中，我们将向读者解释这些改进的细节，以及在此过程中发现的各种安全漏洞。什么是受损的渲染器进程？攻击者在Chromium的渲染器进程中发现安全漏洞并不少见，例如在JavaScript引擎、DOM或图像解析逻辑中。有时这些漏洞可能涉及内存错误（例如UAF漏洞），允许攻击者的网页在呈现期间执行他们自己的、任意的本机代码（例如汇编/C++代码而不是JavaScript代码）。我们称这样的进程为“HackedRenderer”——作者：kaszAnforowicz这意味着一个被黑的渲染器进程不仅可以读取渲染器进程中的所有内存空间，还可以写入它。例如，它允许攻击者伪造从渲染器进程到其他进程的IPC消息。此处列出了站点隔离的改进。启用UXSS的站点隔离绕过漏洞在寻找绕过站点隔离的方法时，我想起了Bo0oM发现的一个非常有趣的UXSS漏洞。当时，SiteIsolation是一个实验性的功能，由于它被禁用，我想知道是否可以利用这个漏洞来绕过SiteIsolation。因此，我在启用站点隔离的情况下测试了UXSS漏洞，发现它在某些方面仍然有效。换源的时候，还是复用之前网站的流量。例如，尝试访问cookie会导致呈现器进程崩溃，因为站点隔离机制认为该进程不应该为另一个来源请求cookie。这简直就是绕过站点隔离的完美漏洞，因为这种行为类似于被攻破的渲染器：我们可以覆盖渲染器进程中的源信息；当然，我们不能以此来绕过进程隔离安全机制。利用此漏洞，我们可以测试哪些API不关心假来源，并允许我们从其他来源访问信息。所以，在测试的时候，我也把这个有趣的行为告诉了Masato。很快，他就发现了一个漏洞。事实证明，我们可以创建一个带有虚假来源的blobURL，只需导航到该blobURL，就能够访问目标网站的cookie。虽然我们发现了上面的漏洞，但是我们必须确保这个漏洞在稳定版本中仍然存在，因为UXSS漏洞已经被修复了。为此，我们验证并发现该漏洞可以在稳定版本上触发，只需在发送IPC以创建blobURL之前通过WinDbg修改源即可。这可以通过在创建blobURL时在浏览器进程中正确验证来源来解决。伪造IPC消息从之前的漏洞中我们可以清楚地看到，通过受感染的渲染器测试站点隔离改进的最简单方法是在渲染器进程发送源或URL信息的地方伪造IPC消息。但是通过阅读代码和使用MojoJS发送假IPC消息来寻找这样的地方似乎是一项艰巨的任务。因此，我为WinDbg创建了一个名为spoof.js的JavaScript调试器扩展。因为spoof.js可以修改渲染器内存中的源和URL，所以我只需要进行正常的WebAPI调用即可完成IPC测试。这也有意想不到的好处，可以伪造传统的IPC消息，而不是Mojo实现的消息（如果我选择使用MojoJS进行测试，这是不可能的）。postMessage中的安全漏洞在使用spoof.js进行测试的过程中，无意中发现postMessage不仅可以发送到跨站窗口/框架，还可以通过伪造源的方式接收来自不同目标源的消息。要修复此漏洞，只需在浏览器进程中相应地验证postMessageIPC的来源即可。用被黑的渲染器欺骗地址栏不幸的是，我只在postMessage中通过spoof.js发现了一个漏洞。之后我就开始思考，能不能通过其他地方的漏洞绕过站点隔离，针对codereview和测试。所以，我决定研究一下导航机制。如果稍微研究一下Chromium的导航机制，您会注意到一个有趣的步骤：渲染器进程在提交导航时向浏览器进程发送IPC消息。这个IPC消息非常有趣，因为渲染器进程可以知道在导航开始后（即在网络进程开始下载响应后）渲染器进程将导航提交到哪个源和URL。如果浏览器进程的验证机制不够严格，很容易出现安全漏洞。在测试导航的处理时，我注意到如果原点是不透明的原点，我可以假装导航已提交到呈现器进程中的任何URL。该漏洞的存在是因为任何URL都可能是不透明的来源（使用iframe/CSP沙箱），因此检查常规来源与URL没有任何意义。目前，此检查已得到增强，以确保无法执行地址栏欺骗。协议处理程序的滥用我的另一个想法是，如果我可以使用registerProtocolHandlerAPI将任何协议导航到某个“坏”URL（例如数据URL）会怎样？因此，我检查了他们的实现代码，发现以下限制可以被绕过/欺骗：协议/方案必须在允许列表中：此检查在渲染器进程中完成，而浏览器进程仅实现处理的协议浏览器（例如http:、https:等）相关的拒绝列表检查。目标URL必须与注册窗口同源。此检查也在渲染器进程中执行，因此可以绕过。用户必须接受权限提示。权限提示中显示的来源是根据目的URL计算得到的，目的URL可以通过上述方法伪造。跨域iframe可以调用registerProtocolHandlerAPI。如果传入DataURL，则权限提示中不会显示任何来源信息。利用这些绕过技术，攻击者可以通过以下步骤绕过站点隔离机制：请求协议处理程序的权限，使用以下数据URL作为目标URL：data:text/html，点击劫持带有自定义协议的协议链接的受害者页面（例如tel:、mailto:等）。单击该链接将导航到上述数据URL，该URL在受害者的渲染器进程中执行。可以通过向浏览器进程添加适当的检查来修复此漏洞。阅读器模式中的安全漏洞当Edge开始提供阅读视图时，我们决定看看DOMDistiller，它为Chrome中的阅读器模式提供支持。很好奇DOMDistiller是如何实现的，于是开始对其进行相应的安全测试。阅读器模式会在呈现之前过滤网站的HTML内容，以获得良好的阅读体验。虽然他们试图删除大部分危险标签（如脚本、样式等），但许多事件处理程序未被正确过滤（如
