一、前言
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 加固措施
该类型的漏洞依赖于使用嵌套时间循环来执行页面加载。加载完成后，漏洞必须继续执行，但是无法在具有常规超时限制或承诺的嵌套循环中进行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漏洞利用的成本将非常接近于完整远程代码执行漏洞利用的成本，包括沙箱逃逸。沙箱逃逸被认为是漏洞利用链中最复杂、成本最高的一项。
还没有评论，来说两句吧...