知往鉴今：Chromium近三年UXSS漏洞分析及缓解、预防和检测措施

一、前言

UXSS（通用跨站脚本攻击）是一种攻击方式，利用浏览器或浏览器扩展中的客户端漏洞，在访问任意资源（来源）时执行恶意代码（通常为JavaScript）。简而言之：

受害者访问恶意网站（被攻陷/被感染）后，攻击者可以阅读受害者的Gmail内容、FaceBook上的私人消息，并可以代替受害者执行其他操作，例如发送电子邮件、上传照片等。

本项研究的主要目的，是分析此前三年来（2014年至2017年）Chromium浏览器中实施的潜在缓解措施，并探索可用于预防或检测UXSS漏洞的新技术。

二、背景

SOP（同源策略）是Web应用程序安全模型中最为重要的概念之一。基本上，它可以防止不同来源互相访问存储在客户端上的数据（即：Cookie、浏览器选项卡的内容、与某些Web应用程序相关的内容、客户端可用的内容）。

Origin是HTML标准中定义的URI方案，是主机与端口的组合。如果两个URI都使用了相同的协议（例如：HTTPS）、相同的主机（例如：google.com）和相同的端口（例如：443），那么就会将二者认为是同源的。否则，会判断两个URI属于不同源，默认情况下不能访问彼此的数据。

在JavaScript中，使用执行上下文（Execution Context）来表示代码被执行的环境。默认情况下的上下文是全局执行上下文（Global Execution Context），通常是在浏览器加载新页面时被创建。每个GEC都有自己的JS内置集，每个JS对象都与执行上下文相关联。API函数通常使用上下文来执行访问检查。

跨站脚本攻击（XSS）是一种客户端代码注入攻击，允许攻击者破坏用户与易受攻击的Web应用程序之间的交互。XSS漏洞通常允许攻击者以受害用户的身份执行任意操作，并访问网站上的任意数据，从而规避SOP。当Web应用程序使用用户提供的输入生成输出内容，而没有进行适当的验证时，就会产生这些漏洞。目前，XSS是最为广泛的Web应用程序攻击类型。

通用跨站脚本攻击（UXSS）可以在浏览器自身或浏览器扩展中利用漏洞来实现XSS的条件，而不再是在Web应用程序中利用漏洞。因此，攻击者不仅可以访问单个网站上的用户会话，还可以访问浏览器当前打开的任何页面，包括内部浏览器页面。对于使用任何浏览器的用户来说，对于任何浏览器来说，导致UXSS攻击的漏洞，都是最重要的威胁之一。Chromium Severity Guidelines将此类漏洞归类为高严重性漏洞。

从攻击者的角度来看，UXSS漏洞利用可能与沙箱逃逸的远程代码执行（RCE）攻击一样有价值，因为UXSS漏洞往往更加可靠，并且在许多情况下可以满足攻击者的需求，除非攻击者的目标是完全攻陷受害者的设备。

在这项研究中，经常涉及到Chromium的多进程架构。有关该主题的更多详细信息，请参阅Chromium的官方文档。本研究中最为相关的内容如下：

1、Browser Process是浏览器应用程序的最主要、特权最高的进程。该进程具有与其计算机上运行Chrome的用户相同的权限，包括对文件系统、网络栈、系统API等的访问权限。浏览器进程控制最高级别的浏览器窗口、用户界面、进程间通信，并进行其他高级管理操作。

2、Renderer Process是一个权限较低的进程，负责向用户显示网页并执行JavaScript。Chromium为浏览器中打开的不同网站创建了多个渲染器进程，其中每个进程都是独立的，并且都在沙箱中运行，因此与攻击浏览器进程（Browser Process）相比，攻击渲染器进程的风险相对更低。

Blink是Chromium使用的渲染引擎。

V8是Chromium使用的JavaScript和WebAssembly引擎。

在部署更新的导航（Navigation）架构（也称为PlzNavigate）之前（2017年10月之前），渲染器进程中的远程代码执行漏洞可以简单地转换为UXSS。其原因在于，导航是由渲染器进程启动的，而恶意代码可以绕过跨源安全检查。在PlzNavigate有效的情况下，浏览器进程负责处理所有导航请求，并执行策略。

此外，在2016年12月以前，将成功的UXSS漏洞利用转换为Android上的远程代码执行漏洞利用是非常简单的。简而言之，攻击者无需任何用户交互，也无需获得任何许可，即可在受害者的设备上安装任意应用程序。在此之后，在通过Web流安装应用程序时，始终会提示用户重新进行身份验证。

在Chrome的漏洞奖励计划中，针对UXSS和渲染器远程代码执行漏洞提交的金钱奖励是相同的。

三、概述

Chromium浏览器及其组件严格执行了同源策略的概念。依靠在Blink和V8上下文的安全模型中使用SOP和站点隔离等新功能，可以在各个层面上解决这一问题。但是，与任何其他复杂的软件项目一样，在某些情况下存在破坏这些保护的漏洞。

本文档对2014至2016年期间报告的导致UXSS攻击的漏洞进行了概述和分析，并得出有关如何在以后缓解这些问题的结论。需要注意的是，在我们所分析的时间范围内，Chromium没有启用PlzNavigate，也没有启用站点隔离功能。

这项研究主要是在2017年年初进行的，因此本文中将“站点隔离”称为即将实现的增强功能，而没有将其视为现有的功能。

3.1 漏洞报告分析

在本文的漏洞报告分析中，针对2014至2016年期间报告的问题，使用以下查询发现了100多个Chromium漏洞：

“UXSS”、“XSS”、“Universal XSS”；

“Cross-Site Scripting”、“Universal Cross-Site Scripting”；

“SOP Bypass”、“SOP”；

“Same Origin Policy”、“Same Origin Policy”；

“Cross-orgin”等。

在首次搜寻到漏洞信息之后，我们进行了初步分析，最终筛选出63个问题作为有效的UXSS报告。随后，我们将这63个问题根据其根本原因或开发模式，进行了分类。最后，对这些类别进行了再次调整，最终形成了8类。有关更详细的内容，请参阅第四章 漏洞分析。

3.2 时间分布

四、漏洞分析

4.1 Blink：滥用解析器启动的JavaScript: URI页面加载

4.1.1 描述

这是本研究中漏洞数量最多的一个类别。

触发JavaScript执行的一种可能方式是执行JavaScript: URI导航。Chromium会检查当前执行上下文的来源（Origin），以确定加载是否成功。如果栈上没有活动的上下文，浏览器会认为导航安全。因此，如果<iframe>元素在其中加载了跨源页面，并且是未附加到文档的子树的一部分，就可以强制HTML解析器将元素插入到文档中，并加载任意JavaScript: URI。

4.1.2 加固措施

来自Daniel Cheng的评论（ [email protected] ）：

关于解析器，我们有一个假设，如果栈上没有JavaScript上下文，那么执行JavaScript: URI总是安全的，我们假设这是解析器触发的。但遗憾的是，一些VRP报告注意到了这些假设，并将其与DOM损坏攻击相结合，DOM损坏始终是来自不同的来源，但其目标是在危险的情况下触发这种假设。针对于此，我们提出了一般性的缓解方案，请参见 https://codereview.chromium.org/2502783004/ 以及 https://codereview.chromium.org/2190523002/ 。

最后需要强调的是，我们应该改变JavaScript: Navigation永远不进行同步。在一些具体的实例中，它们会进行同步，这只会产生问题。

4.1.3 报告

（1）2015年2月7日（ 456518 ）HTML解析器可能会使frame元素处于不正确的状态

（2）2015年3月5日（ 464552 ）在blink::ContainerNode::attach中利用堆Use-After-Free漏洞

（3）2015年8月3日（ 516377 ）blink::ContainerNode::parserRemoveChild中的UAF/DOM树损坏

（4）2015年8月11日（ 519558 ）ContainerNode::parserInsertBefore通用XSS漏洞

（5）2015年10月8日（ 541206 ）使用document.adoptNode的通用XSS漏洞

（6）2015年11月16日（ 556724 ）通过子框架持久化的通用XSS漏洞

（7）2015年11月22日（ 560011 ）ContainerNode::parserRemoveChild中更新 工具 的通用XSS漏洞

（8）2016年1月13日（ 577105 ）通过绕过卸载事件的通用XSS漏洞

（9）2016年4月21日（ 605766 ）采用图像元素导致的通用XSS漏洞

（10）2016年6月19日（ 621362 ）Flash调用JavaScript insideNode::removedFrom导致的通用XSS漏洞

（11）2016年7月24日（ 630870 ）拦截UA阴影树导致的通用XSS漏洞

（12）2016年9月8日（ 645211 ）使用blink::HTMLMarqueeElement的通用XSS漏洞

（13）2016年10月14日（ 655904 ）通过全屏元素更新的通用XSS漏洞

（14）2016年10月22日（ 658535 ）使用<input type="color">元素的通用XSS漏洞

（15）2016年11月8日（ 663476 ）通过删除链接元素的通用XSS漏洞

（16）2016年11月24日（ 668552 ）通过使用命名来污染私有脚本的通用XSS漏洞

4.2 Blink：缺少或不正确使用跨源访问检查

4.2.1 描述

这一类漏洞相对简单。在执行敏感操作时，浏览器应该确保当前上下文（或当前页面）具有适当的权限。在下面列出的漏洞中，该检查完全缺失，或者在错误的上下文之中执行。

Bug 504011就是这类问题的一个典型示例。首先，攻击者泄漏V8ContextNativeHandler的GetModuleSystem()函数。然后，他们使用另一个来源的跨源窗口对象调用该函数。实际上，在这里不应该创建跨源引用，但是由于缺少访问检查，该函数调用在另一个源的上下文中返回所请求的模块对象。

针对这样漏洞的修复通常比较简单，例如针对上述示例中的漏洞，其修复方式如下：

1、在存在漏洞的函数中 调用帮助函数 进行访问检查；

2、使用BindingSecurity API 实现该帮助程序 。

4.2.2 加固措施

请参阅 https://crbug.com/525330 ，在分离框架/窗口时立即清空DOMWindow::m_frame。

Chromium使用具有不同生命周期的对象来表示页面。例如，在导航之间保留Frame对象，但会为每个页面加载创建一个新的DOMWindow。DOMWindow对象用于存储对框架的引用，即使在它们已被分离的情况也同样适用。这样就导致了很多问题，其中，跨源框架的访问检查是在同源的分离窗口上执行的。该补丁修复后，使清除框架引用成为了可能。

4.2.3 报告

（1）2014年2月11日（ 342618 ） iframe上的dispatchEvent存在UXSS漏洞

（2）2015年6月24日（ 504011 ） 通过模块系统泄漏可能实现跨源脚本

（3）2015年8月20日（ 522791 ） 使用navigator.serviceWorker.ready的通用XSS漏洞

（4）2015年8月24日（ 524074 ） 加载已经卸载的JavaScript: URI导致通用XSS漏洞

（5）2015年9月9日（ 529682 ） 内容脚本能够在其他扩展的后台页面中评估代码

（6）2016年8月17日（ 638742 ） 使用ThreadDebugger::setMonitorEventsCallback的通用XSS漏洞

4.3 Blink和V8：使用的上下文不正确

4.3.1 描述

在创建新的JS包装器（Wrapper）对象时，Blink方法通常必须要确定正确的创建上下文。当用于创建上下文源的值可以被用户控制时，就会发生此类漏洞。

以Bug 632634为例，静态方法的 绑定代码 允许将info.Holder()（其参数的方法）设置为任意值。然后，info.Holder()的创建上下文可用于返回ScriptState对象，当从静态方法执行时，该对象最终变为跨源引用。

在修复补丁中，包含两个不同于先前易受攻击的 forHolderObject()函数实现 （forFunctionObject()和forReceiverObject()）。这些实现将根据调用方法或属性是否为静态来选择使用。

这一类中的许多问题都滥用了JS异常创建。Bug 453979就是这样的一个例子：

当DOM方法抛出异常时，异常对象的创建上下文继承自调用该方法的对象，即使它来自不同的源。创建对象的过程中，没有进行任何访问权限检查，因此攻击者可以借助它来获取一些引用，例如函数构造函数。

针对这些问题的修复方法，通常包括在抛出异常时对创建上下文进行清理。另一个修复方法是，将跨站点异常（Cross-site Exception）转换为安全错误（Security Errors）。

最后，Bug 583445是另一个值得关注的例子。在这种情况下，浏览器在导航后没有更新执行的上下文，因此在新页面中，将在前一个上下文中运行JavaScript。

4.3.2 报告

（1）2015年1月30日（ 453979 ） V8中异常对象导致的UXSS

（2）2015年5月31日（ 494640 ） 使用IDBKeyRange静态方法的通用XSS漏洞

（3）2015年9月10日（ 530301 ） 使用栈溢出异常的通用XSS漏洞

（4）2015年9月15日（ 531891 ） 使用从Object.observe抛出的异常的通用XSS漏洞

（5）2016年2月2日（ 583445 ） DocumentLoader::createWriterFor中的通用XSS漏洞

（6）2016年4月22日（ 605910 ） 使用iterables的通用XSS漏洞

（7）2016年4月28日（ 607483 ） 转换IDL数组/序列中存在的通用XSS漏洞

（8）2016年5月31日（ 616225 ） V8Console::memoryGetterCallback中存在的通用XSS漏洞

（9）2016年7月29日（ 632634 ） 静态方法和ScriptState::forHolderObject存在的通用XSS漏洞

（10）2016年10月15日（ 656274 ） 通过提取（Fetch）实现跨源对象泄漏

4.4 Navigation：isNavigationAllowed()绕过、丢失或绕过ScriptForbiddenScope等

4.4.1 描述

这是最新的一类漏洞。在2016年，共报告了8个此类漏洞中的7个。

该类漏洞结合了在页面导航逻辑中存在的弱点，来破坏两个不变量中之一。第一个无法执行同步跨源页面加载。这样一来就可能导致UXSS，因为TOCTOU问题与加载<iframe>元素中的JavaScript:URI有关。第二个是两个文档不能同时附加到同一个Frame对象。如果其中一个文档是同源的，另一个是跨源的，那么攻击者就可以使用前者来修改后者，而Frame则充当代理。

Bug 616907就是一个很好的例子：

这是ScopedPageLoadDeferrer实现的架构问题。基本上，它通过在实例化延迟器时，通过将页面标记为延迟来工作。但问题在于，在此之后创建的页面，默认情况下不会延迟加载。攻击者可以跨越延迟边界移动iframe，这允许在意外情况下进行同步跨源导航。

其修复方法是，在实例化延迟器时，禁用打开新页面。

另外一个值得关注的漏洞是Bug 600182：

当ScopedPageLoadDeferrer被销毁时，会在关联的页面和加载器上更新延迟状态。如果在事件循环期间预留任何历史加载，那么延迟器将始终对其进行保护，在更新期间将会直接进行处理，而不检查框架是否允许导航。

这样一来，就为攻击者绕过FrameNavigationDisabler提供了一条途径。

针对这一漏洞的修复方法是，将isNavigationAllowed()检查移动到主入口点以进行加载。

4.4.2 加固措施

请参阅 https://crbug.com/629431 。

该类型的漏洞依赖于使用嵌套时间循环来执行页面加载。加载完成后，漏洞必须继续执行，但是无法在具有常规超时限制或承诺的嵌套循环中进行JavaScript回调。该类问题的修复布丁中，解决了扩展API中的一个问题，这一问题允许攻击者绕过限制。

4.4.3 报告

（1）2015年10月22日（ 546545 ） 使用插件对象的通用XSS漏洞

（2）2016年3月24日（ 597532 ） 使用FrameNavigationDisabler绕过的通用XSS漏洞

（3）2016年4月3日（ 600182 ） 使用延迟历史记录加载的通用XSS漏洞

（4）2016年4月8日（ 601706 ） 使用负载延迟逻辑中的缺陷导致的通用XSS漏洞

（5）2016年5月19日（ 613266 ）  通过FrameLoader::startLoad的重新进入实现通用XSS漏洞

（6）2016年6月2日（ 616907 ） 使用ScopedPageLoadDeferrer绕过的通用XSS漏洞

（7）2016年6月6日（ 617495 ） 使用相同文档导航的通用XSS漏洞

（8）2016年7月17日（ 628942 ） 带有ScopedPageLoadDeferrer和RemoteFrame的通用XSS漏洞

（9）2016年9月13日（ 646610 ） 使用OOPIF的通用XSS漏洞

（10）2016年12月5日（ 671102 ） 通过绕过ScopedPageSuspender关闭窗口的通用XSS漏洞

（11）2016年12月11日（ 673170 ） 使用最新小工具更新的通用XSS漏洞

4.5 扩展API：函数或对象的泄漏，以及使用任意或未经授权的createContext

4.5.1 描述

扩展的系统可以访问JavaScript内部的特定位置，同时还为用户上下文提供公共API。由于在API实现中存在不同的错误，因此有一些技巧可以实现对扩展API的滥用。

这一类漏洞的主要目标都是泄漏内部对象。例如Bug 590275：

RequireForJsInner在内部对象调用GetProperty，该对象用于存储模块系统的导出函数。在Object.prototype上定义的getter函数可能会泄漏该对象。随后，泄漏的对象将用于获取跨源访问，例如：

1、通过本地函数（例如Bug 590118中的user_gestures.RunWithUserGesture）；

2、通过滥用SendRequestNatives::GetGlobal来获取Bug 546677中的受害者窗口对象。

针对不同的漏洞，应用了不同的修复程序。其中，一个值得注意的例子是：

1、停止在公共API中使用给定的creationContext；

2、加强对绑定的拦截。

4.5.2 报告

（1）2015年6月6日（ 497507 ） 通过本地函数实现跨源脚本

（2）2015年9月22日（ 534923 ） 通过unload_event模块实现通用XSS

（3）2015年10月22日（ 546677 ） SendRequestNatives :: GetGlobal的通用XSS

（4）2016年2月26日（ 590118 ） 使用截获的本地函数的通用XSS

（5）2016年2月26日（ 590275 ） ModuleSystem::RequireForJsInner内部对象泄漏导致通用XSS漏洞

（6）2016年3月26日（ 598165 ） 通过Object.prototype.create拦截绑定导致的通用XSS漏洞

（7）2016年4月6日（ 601073 ） 扩展绑定中的通用XSS漏洞

（8）2016年4月19日（ 604901 ） 通过SchemaRegistry实现的持久化通用XSS漏洞

4.6 V8：缺少或不正确使用访问检查

4.6.1 描述

这一类漏洞与第2类相似，唯一的区别是检查的位置应该位于V8端。

以Bug 354123为例：

Object.setPrototypeOf的当前实现没有任何安全检查。为了实现UXSS漏洞利用，攻击者可以用一个对象来替换受害者的窗口原型，该对象具有重新定义的默认方法/属性访问器，从受害者的JS上下文中泄漏对象。

针对该漏洞，其解决方案非常简单，只需添加必须的访问调用检查即可。

4.6.2 报告

（1）2014年3月19日（ 354123 ）

（2）2015年2月6日（ 455961 ）

（3）2016年6月10日（ 619166 ）

4.7 特定于Flash的问题

4.7.1 描述

在Flash插件中，有其自身的SOP策略实现。该类漏洞结合了插件自身中缺少的安全检查，以及Chromium的代码中对Flash的支持问题。

这一类的大多数错误，都是由Adobe进行修复的。针对Bug 569496的修复方法，是为了防止PPB_Flash_MessageLoop中的页面加载。

4.7.2 报告

（1）2014年10月20日（ 425280 ） 使用文件上传和重定向绕过Flash跨域策略（仅限Chrome）

（2）2015年4月27日（ 481639 ） 通过ActionScript的Sound对象实现通用SOP绕过

（3）2015年12月14日（ 569496 ） 使用Flash消息循环导致通用XSS漏洞

4.8 自定义问题：外部依赖项、自定义模式（例如：设计模式、DevTools）、插件（例如：Pepper）和特殊资源类型

4.8.1 描述

该类漏洞的原因在于Chromium代码库的不同部分，没有任何通用的模式和规律。实际上，可以将这些漏洞单独分为一类，但我们将其放在“自定义问题”的分类中，似乎更加合理一些。

由于漏洞的性质不同，所以修复程序也完全不同。

其中，有两个问题（Bug 429542和Bug 594383）都是由file://协议的特殊处理引起的。其修复方式为：

1、使“file:”成为有效的唯一来源；

2、在初始化主框架之前应用WebSettings。

4.8.2 报告

（1）2014年11月2日（ 429542 ） Linux上通过/proc/self/fd/实现文件到文件SOP绕过

（2）2014年12月23日（ 444927 ） 继承的designMode和跨窗口拖放允许修改跨源iframe的DOM

（3）2015年2月28日（ 462843 ） AuthenticatorHelper中存在UXSS漏洞

（4）2015年12月15日（ 569955 ） 使用全屏API导致通用XSS漏洞

（5）2016年3月13日（ 594383 ） file://页面window.open()存在UXSS漏洞

（6）2016年8月14日（ 637594 ） 使用DevTools的通用XSS漏洞

4.9 不同类别的报告分部

4.10 时间组合视图

五、其他浏览器中的UXSS漏洞

实际上，并不仅仅在Chromium中才存在UXSS漏洞，每个主流浏览器都曾经出现过该类型的漏洞。我们列举一些实例，并将它们与Chromium定义的类别进行比较。

5.1 Safari

Chromium和Safari曾经共同使用相同的渲染引擎，因此本文中列出的许多旧Bug也会影响Safari。最近的一个例子是 https://bugs.chromium.org/p/project-zero/issues/detail?id=1068 ，这是JavaScriptCore绑定中的一个错误，Safari的JavaScript引擎与Chromium的V8不同，它与第3类完全匹配。其中一个参数用于确定异常对象的创建上下文。攻击者可以传递一个跨源对象作为参数，从而获得一个跨源异常，该异常暴露了另一个来源的构造函数。

针对该漏洞的修复，对函数进行了修改，以直接通过 附加参数 获取上下文。

5.2 Edge

CVE-2017-0002 演示了处理about:blank页面的错误。这些页面的特殊之处在于它们无法从URL派生它们的源，而是继承了打开者或者父页面的来源。错误地实施此行为，可能会导致违反SOP。在这种情况下，一个未继承其源的about:blank页面（例如：一个空页面）能够访问任何其他about:blank页面。这个漏洞上实际上几乎与此前Chromium的 Bug 89453 相同，都属于第8类。

遗憾的是，针对该漏洞的修复，没有发布公开的链接。

5.3 Firefox

在Firefox中，我们发现了一个 值得注意的漏洞 ，对特殊字符的错误处理允许攻击者欺骗页面URL。即使内部代码仍然能够从欺骗URL中正确地确定源，Flash插件也会将欺骗部分视为实际的域名。因此，攻击者可以在受害者页面的上下文中运行ActionScript代码。该漏洞属于第7类。

其修复方法是改进了 URL的验证方式 。

5.4 小结

可以看出，本文中介绍的漏洞分类也同样适用于其他浏览器，并且针对不同浏览器，可能存在一些相同的漏洞。这样一来，我们这篇文章，可能对Chromium之外的浏览器中实现UXSS防御有所帮助。

六、潜在缓解措施及应对方法

在本节中，主要介绍了一些检测或缓解UXSS漏洞的方式，以及这些方式所带来的警示。这些方案与上述任何特定类别无关，属于通用的方法。

6.1 DataFlowSanitizer Instrumentation

DataFlowSanitizer 是用于广义动态数据流分析的存储器工具。 DFSan API 允许使用标记来标记内存中的任何字节。DFSan在复制数据时同样也会附带标签。对于某些操作（例如：添加），如果源操作数具有不同的标记，那么这些标记将被连接，以形成新的组合标记。然后，在程序执行的任何时刻，我们可以查询哪些标签被附加到特定的内存字节。

理论上，这种方法可能最终可以跟踪对象所关联的起源，并根据分配的DFSan标记执行访问检查。但是，对于这一类漏洞，这样的方法似乎比较低效。我们不可能在基本类型（如WTF::String或WTF::Vector）内为内存字节分配适当的标记，因为这些类型的对象不清楚它们的关联起源，甚至是相关的框架。

6.2 通过DOM Wrappers进行原始清理

之前讨论过得另一个提议被称为 “针对每个源的内存保护” 。简短来说，该提议是指将源与DOM包装器相关联，并将所有入口点从V8挂钩到Blink（可能还有一些从Blink到V8的入口点）。

正如提议文档中所说的那样，保护包装器访问不足以阻止UXSS攻击。有许多方法可以在不经过包装的情况下利用UXSS。因此，这可能不是一个太好的方案，但无论如何，它有助于防止导致UXSS的许多漏洞。

6.3 对UXSS漏洞进行模糊测试

在一些漏洞报告（例如：https://crbug.com/497507 和 https://crbug.com/504011）中，使用了以下的方法来演示UXSS利用。一个无害的parent.html页面嵌入了child.html页面，该页面执行漏洞利用，并最终访问父页面。然后，通过修改父页面的背景颜色来实现演示。

假设我们有可能通过执行由Fuzzer生成的JavaScript代码，来获得跨源访问，我们可以通过以下方式进行模糊测试。

1) 模糊测试过程对一组HTML文件进行操作：

Parent.html是具有常量内容的约束，大致如下所示：

<!doctype html>
<title>Parent</title>
<body>
<script>
...
var savedState = deepCopy(window);
setTimeout(() => verifyState(window, savedState), TIMEOUT);
</script>
<iframe sandbox="allow-scripts" src="child.html"></iframe>
</body>

child.html包含生成的JavaScript代码，并执行任意API方法调用和DOM树操作。我们可以使用现有的模糊器来生成此类文件。

2) deepCopy方法创建JavaScript窗口对象当前状态的快照。由于大多数DOM对象通常具有可以从窗口访问的JS包装器，因此它们也包含在快照之中。

3) 在child.html中的代码运行一段时间之后，verifyState遍历对象树将其与快照进行比较。如果不匹配，则可能表示SOP违规。

关于如何使用模糊测试来发现SOP绕过，我们有另外一个思路，可能会应用于现有的Fuzzer上。具体是，在现有Fuzzer生成的每个测试用例结束时，验证document.origin。如果原始值符合以下条件，则报告错误：

针对通过HTTP提供的测试用例，不应等于 http://localhost:8000 ；

针对直接从磁盘打开的测试用例，不应等于null。

然而，正如我们之前所描述的，大多数已知的SOP绕过都是逻辑漏洞，而不是内存损坏的漏洞。因此，自动生成触发SOP绕过的Payload将比通过使用不同JavaScript对象执行的随机操作触发内存损坏漏洞Payload的生成要困难得多。

另外一个有趣的观点是，渲染器进程中的代码执行漏洞基本上等同于UXSS。其原因在于，代码执行使攻击者可以覆盖安全检查，并获得跨源访问。需要注意的是，这在 PlzNagivate 启动后不适用。

6.4 站点隔离

在研究期间，我们分析的绝大多数漏洞都使用跨站框架。在这种情况下，不同的来源通常会共享相同的渲染器进程。因此，SOP绕过问题的攻击面非常大：

1、Blink、Bingings、V8中的逻辑错误；

2、扩展和其他API；

3、导致远程代码执行的内存损坏漏洞。

站点隔离 项目旨在添加对每个进程的站点策略的支持，以确保所有渲染器进程包含来自至多一个网站的文档。在2017年初，这项研究最初进行时，站点隔离看上去对于缓解UXSS攻击非常有价值。

现在，我们可以使用站点隔离，它于2018年年中 部署 在Chromium的桌面版本中，受损的渲染器无法在不绕过沙箱限制的情况下访问另一个站点，这样一来就显著提高了攻击者所花费的成本。因此，与上述攻击面相比，沙箱的攻击面要小很多。

值得注意的是，站点隔离仍然存在一些局限性。首先， 站点隔离设计文档 对站点有严格的定义：页面的站点包括协议和注册的域名，包括公开后缀，但忽略子域名、端口和路径。这与源的定义不完全匹配，否则某些浏览器功能将非常难以实现（例如：document.domain修改）。因此，当攻击者能够在与受害者相同的二级域名和协议中运行JavaScript时，站点隔离将无法保护免受UXSS攻击。

其次，像<img>和<script>这样的一些Web功能在历史上允许跨源请求。Chromium使用跨源资源阻止（CORB）来防止它们用作泄漏敏感的跨源数据的方法。但是，CORB使用内容类型嗅探，这可能会在某些极端情况下产生不正确的结果，并且只保护JSON、XML和HTML数据，因此它不会阻止攻击者窃取JS、CSS和媒体文件。

七、总结

站点隔离是针对UXSS攻击最有效的对策，主要在于它将击破绝大多数依赖于统一进程跨源帧的可用性的UXSS漏洞。在Chromium中部署站点隔离后，UXSS漏洞利用的成本将非常接近于完整远程代码执行漏洞利用的成本，包括沙箱逃逸。沙箱逃逸被认为是漏洞利用链中最复杂、成本最高的一项。