接下来是《深入分析站点隔离机制》，Part 1》
在上一篇文章中，我们向读者解释了如何缓解网站隔离和相关安全机制UXSS和Spectre黑客攻击等。然而，由于渲染器过程中的安全漏洞非常常见，因此，Chromium假设渲染器过程可能会被入侵，这是不可信的。为了与这种威胁模型保持一致，Chromium为了进一步缓解入侵渲染器过程中可能造成的危害，2019年宣布了网站隔离机制的相应改进。在本文中，我们将向读者解释这些改进的细节和在此过程中发现的各种安全漏洞。
入侵的渲染过程是什么？
攻击者可能在那里Chromium在渲染过程中发现安全漏洞，如JavaScript引擎、DOM或者在图像分析逻辑中，这并不罕见。有时，这些漏洞可能涉及内存错误(例如，UAF漏洞)，导致攻击者的网页在渲染过程中执行自己的、任意的、本地的代码(如汇编/C 代码，而不是JavaScript代码)。我们称这样的进程为“入侵渲染器”——作者：kasz Anforowicz
这意味着入侵的渲染过程不仅可以读取渲染过程中的所有内存空间，还可以写入操作。例如，允许攻击者伪造渲染过程IPC给其他流程消息。这里列出了网站隔离的改进。
一个可以实现UXSS网站隔离绕过漏洞
在寻找绕过现场隔离的方法时，我想起了Bo0oM一个非常有趣的发现UXSS漏洞。当时网站隔离只是一个实验功能，出于禁用，我想知道是否可以利用这个漏洞绕过网站隔离措施。
因此，我启用了现场隔离机制UXSS漏洞进行了测试，发现它在某些方面仍然奏效。当源发生变化后，之前网站的流程仍会被重用。例如，如果试图访问cookie，由于网站隔离机制认为这个过程不应该是另一个源请求，渲染器过程会崩溃cookie。
这是一个完美的漏洞，可以用来绕过网站隔离，因为这种行为类似于入侵渲染器：我们可以覆盖渲染器过程中的源信息；当然，我们不能绕过过程隔离安全机制。我们可以测试哪个漏洞API我在乎伪造的来源，允许我们访问其他来源的信息。所以，在测试的同时，我也告诉了这个有趣的行为Masato。很快，他发现了一个漏洞。事实证明，我们可以创建一个伪造源Blob URL，而且，只要导航到这里，Blob URL，您可以访问目标网站cookie。
虽然我们发现了上述漏洞，但我们必须确保它仍然存在于稳定版中，因为UXSS漏洞已经修复了。为此，我们验证并发现只要发送IPC创建Blob URL之前通过WinDbg修改源可以在稳定版本中触发这个漏洞。
在创建Blob URL时，通过在浏览器进程中对源进行相应的验证，就能修复这个问题。
伪造IPC消息
从上一个漏洞可以清楚地看出，通过入侵渲染器测试站隔离改进的最简单方法是在渲染器过程中发送源或URL伪造信息的地方IPC但是，通过阅读代码来找到这样的地方并使用它Mojo JS发伪造的IPC新闻，似乎是一个巨大的项目。
于是，我为WinDbg创建了一个名字spoof.js的JavaScript因为spoof.js可以修改渲染器内存中的源和URL，所以，我只需要做正常的事情Web API可以通过调用来完成IPC测试工作。这样做还有一个意想不到的好处，那就是也可以伪造传统IPC消息，而非Mojo实现的IPC消息(如果我选择的话Mojo JS不可能进行测试)。
postMessage中安全漏洞
在使用spoof.js在测试过程中，我意外地发现不仅可以postMessage发送到跨站点的窗口/frame也可以通过伪造源收到来自不同目标源的消息。
为了修复这个漏洞，只要在浏览器的过程中postMessage IPC相应验证源。
使用入侵渲染器欺骗地址栏
不幸的是，我通过了spoof.js只在postMessage发现了一个漏洞。之后，我开始思考是否可以绕过其他地方的漏洞，以确定代码审查和测试的目标。所以，我决定研究导航机制。
假如你稍微研究一下Chromium导航机制将找到一个有趣的步骤：渲染过程将在提交导航时向浏览器过程发送一个IPC消息。这个IPC这个消息非常有趣，因为渲染器过程可以在导航启动后（即网络过程已经开始下载响应），知道渲染器过程将提交导航到哪个源URL。若浏览器过程的验证机制不够严格，则容易出现安全漏洞。
在测试导航的处理过程时，我注意到，如果源是一个不透明的源(opaque origin)，我可以假装导航已经提交给渲染器进程URL。这个漏洞之所以存在，是因为有任何漏洞URL可以是不透明源(使用)iframe/CSP沙箱)，所以传统的来源和URL检查毫无意义。目前已加强检查，确保地址栏欺诈无法实施。
滥用协议处理程序
我的另一个想法是，如果我能用的话registerProtocolHandler API导航任何协议“坏”的URL(例如Data URL)，结果如何？因此，我检查了他们的实现代码，发现以下限制可以绕过/欺骗：
协议/scheme必须位于allow-list中：
- 该检查是在渲染过程中进行的，浏览器过程只与浏览器达成协议(例如http:,https:等)相关的deny-list检查。
- 目标URL必须与注册窗口同源。
- 这种检查也是在渲染过程中进行的，所以可以绕过。
- 用户必须接受权限提示。
- 权限提示中显示的源是目的URL计算，目的URL上述方法可以伪造。
- 跨源的iframe可以调用registerProtocolHandler API。
- 如果传递Data URL，源信息不会显示在权限提示中。
通过这些绕过技术，攻击者可以通过以下步骤绕过现场隔离机制：
- 请求协议处理程序的权限，请求以下权限Data URL作为目标URL：data:text/html,点击劫持带有自定义协议链接的受害者页面(如tel:、mailto:等)。
- 点击此链接将导航到上面Data URL，该URL在受害者的渲染过程中执行。
这个漏洞可以通过在浏览器过程中添加适当的检查来修复。
Reader模型下的安全漏洞
当Edge当我们开始提供阅读视图时，我们决定进行调查DOM Distiller，其作用是为Chrome中的Reader模型提供支持。我很好奇。DOM Distiller它是如何实现的，行相应的安全测试。
Reader渲染前，模式会对网站进行渲染HTML过滤内容以获得良好的阅读体验。尽管他们试图删除大多数危险标签(如script、style等等)，但许多事件处理程序没有适当过滤(如< button onclick="alert(1)" >)。根据相应的设计显示网站的图片和视频。
这本质上意味着，如果攻击者能够利用图像或视频分析中的内存来破坏漏洞，或者绕过CSP，攻击者可以入侵Reader或在模式过程中Reader脚本在模式下执行。
Reader呈现模式为chrome-distiller:scheme，主机叫GUID，url参数指向要处理的页面，如：
而且，因为它可以重用GUID为了呈现其他跨站点页面，攻击者可以使用以下步骤Reader模式：
- 打开新窗口进入受害者网站(Reader该模会缓存页面)。
- 使用相同的GUID导航受害者窗口Reader模式。
- 此时，攻击者的窗口和受害者的窗口将处于同一过程中，使其能够窃取机密信息。
添加到主机名中url这个漏洞可以通过参数的哈希值和改进过滤措施来修复。
由此可见，Reader模型的设计非常脆弱，因为同一过程可以处理来自不同网站的敏感数据，而且很容易被攻击者入侵。如果你从中学习“The Rule of 2”创意，所以网站被隔离“The Rule of 2”就是：
其他研究人员发现的网站隔离绕过了方法
事实上，其他研究人员已经发现了许多很好的网站隔离方法。
小结
在上一篇文章中，我们向读者解释了如何缓解网站隔离和相关安全机制UXSS和Spectre黑客攻击等。但由于渲染器过程中的安全漏洞很常见，因此，Chromium假设渲染器过程可能会被入侵，这是不可信的。为了与这种威胁模型保持一致，Chromium2019年缓解入侵渲染器过程中可能造成的危害，2019年宣布了网站隔离机制的相应改进。在本文中，我们将向读者解释这些改进的细节和在此过程中发现的各种安全漏洞。由于本文篇幅较长，分为两部分发表。我们将在下一篇文章中介绍更多精彩的内容。
(未完待续)
本文翻译自：https://microsoftedge.github.io/edgevr/posts/deep-dive-into-site-isolation-part-2