记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

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

2019-05-17 12:25

一、前言

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 时间分布

1.png

四、漏洞分析

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漏洞

2.png

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漏洞

3.png

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.png

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漏洞

5.png

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漏洞

6.png

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

7.png

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漏洞

8.png

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漏洞

9.png

4.9 不同类别的报告分部

10.png

4.10 时间组合视图

11.png

五、其他浏览器中的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漏洞利用的成本将非常接近于完整远程代码执行漏洞利用的成本,包括沙箱逃逸。沙箱逃逸被认为是漏洞利用链中最复杂、成本最高的一项。

本文翻译自:https://ai.google/research/pubs/pub48028如若转载,请注明原文地址: http://www.hackdig.com/05/hack-55051.htm
知识来源: https://www.4hou.com/vulnerable/17663.html

阅读:72777 | 评论:0 | 标签:漏洞 Chromium xss

想收藏或者和大家分享这篇好文章→复制链接地址

“知往鉴今:Chromium近三年UXSS漏洞分析及缓解、预防和检测措施”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云