如需转载请注明出处，侵权必究。
本文发表于NDSS2022，第一作者是来自约翰斯霍普金斯大学的Zifeng Kang博士。
论文提出了名为 ProbetheProto 的针对于客户端原型污染的漏洞挖掘工具，并且实现了对一百万个真实世界网站的客户端原型污染漏洞及其后果的首次大规模测量。结果显示，2738个真实世界的网站（包括前1000个网站中的10个）易受2917个原型污染零日漏洞的影响；不仅如此，由于原型污染的存在，48个漏洞会进一步导致XSS，736个漏洞会导致 cookie操控，830个漏洞会导致URL操控。
背景
原型链污染漏洞是JavaScript语言中一种较为新型的漏洞，于2018年首次被提出。这种漏洞的存在是由于JavaScript的一个特性，称为原型链，这个特性允许不仅允许在当前对象中进行属性查找，还可以通过原型链对象进行属性查找。更具体地说，原型污染使攻击者能够注入或修改原型对象下的属性，例如Object.prototype，从而影响到易受攻击的程序。
原型链污染可能造成严重的后果，例如，如果与原型污染漏洞位于同一位置的另一段JavaScript代码通过循环遍历被污染对象下的所有属性以生成HTML代码，则此原型污染将允许攻击者注入任意JavaScript代码，导致到跨站点脚本(执行攻击XSS)。
尽管有一些文章或者项目对原型污染进行了研究，但是它们对原型链污染可能造成的进一步后果研究尚且不充分，尤其是在现实世界网站中的客户端JavaScript代码中造成的后果。先前的一些学术工作仅能检测到服务器端Node.js应用程序中原型污染漏洞的存在，但没有进一步检测到它们造成的后果。有一些技术博客和开源项目仅说明了人工分析出的一些潜在后果，但并不能够自动分析现实世界网站中的漏洞后果，因此也无法实现大规模测量评估。先前研究工作中检测服务器端原型污染漏洞的方法因为其自身的局限无法应用到客户端中。如ObjLupAnsys工具的抽象解释技术过于重量级，会导致路径爆炸等问题。DAPP的误报率非常高（超过50%），且只能依靠专家人工确认漏洞的可利用性。Arteau使用一组预定义的服务器端漏洞利用输入来探索Node.js包的导出函数，而这种方法不适用于客户端，因为客户端的输入多样化且只有部分输入与漏洞直接相关，而其余的可能用于满足攻击成立的条件。
在本文中，作者实现了PROBETHEPROTO工具。本文提出了“联合污点流”概念，用于分析多次属性查找操作导致的原型对象污染漏洞。此外工具采用了多轮执行的方案，且通过前面执行记录的信息来调整后面执行的输入的方式来生成有效的输入以触发找到的原型对象污染漏洞。本文利用工具首次对100万个真实网站中客户端原型污染漏洞及其后果进行了大规模评估。
工具的整体的架构如下图所示，下面将进行详细的解释。
挑战与解决方法
大规模评估客户端的原型污染漏洞主要有两方面的挑战：
首先，成功的原型污染以及进一步的后果通常由两个或多个属性查找操作组成。也就是说，一个原型污染漏洞涉及到多个按特定顺序调用的接收点，而传统的污点传播漏洞中仅有一个接收器。因此，PROBETHEPROTO提出了“联合污染流”概念并加以追踪，以在属性查找和赋值期间检测原型污染。这里文章提出了一个新的概念，称作对象污点。传统的污点被称作“值污点”， 即那些可以直接控制其值的污点。对于一个属性查找操作obj[prop]来说，如果其属性（即prop）是一个“值污点”，那么该操作产生的结果也会被污染，因为可以控制prop的值为"__proto__"来实现使得属性查找的结果指向原型对象，该结果被称作“对象污染”。以o=obj[prop]这个语句为例为例，如果属性（即 prop）被为一个值污染，则o是一个对象污染。当PROBETHEPROTO检测到一条类似 o[prop1]=value 的属性赋值语句，且其中o是对象污染，prop1和value是值污染时，工具可以通过该处三个不同污点流的交汇语句判定存在原型污染漏洞，因为此处原型对象的属性值可以被修改为任意值。
其次，与原型污染后果相关的最终接收点可能无法直接到达。例如，接收点所在的控制流路径可能仅在对象下的某个属性存在时才被触发。为了解决这个问题，PROBETHEPROTO中包含一个“输入/漏洞利用”生成模块，通过根据运行过程中的属性查找操作及污点接收点信息来主动创建对象属性。具体来说，PROBETHEPROTO会执行多次动态污点分析过程。一次运行将记录原型中缺失的属性查找操作和中间接收点；然后PROBETHEPROTO将在后续运行的输入中包含这些缺失的属性，以到达最终与原型污染漏洞后果相关的接收点，例如用于XSS漏洞中的innerHTML或setAttribute以及用于缓存操控的document.cookies。
结果验证
识别出可能的原型对象污染漏洞之后，还要对它们进行验证。首先是关于漏洞及其后果的验证。对于漏洞的验证，工具会给漏洞利用输入一个独一无二的值，在检测完漏洞之后到原型对象里去检查是否存在刚开始输入的值，如果找到了则说明原型对象成功被污染了，漏洞存在。对于漏洞后果的验证，工具主要关注了3中类型的常见后果。对于XSS，工具会注入console.log语句打印一个独一无二的值，并在漏洞触发之后检查控制台里是否存在该值来确认漏洞是否造成了XSS利用；对于缓存操控，工具会检测注入的值是否存在于缓存中；对于URL操控，工具会检查对应HTML元素的URL部分是否包含注入的值的信息。
漏洞利用及其后果确认完成之后，作者会通知网站管理者。作者会提供漏洞的位置信息、漏洞的利用方式以及修复漏洞的方法。
此外，工具还会去检测网站中一些对抗原型对象污染漏洞的方法。作者通过比较两次动态分析过程中污点以及数据流的数量来判定网站存在哪种防御方式。如果两次运行过程中的数据流数量不同，工具会认为网站中存在控制流方面的防御措施，如通过hasOwnProperty等方法阻止污点数据流向接收点。如果两次动态分析过程中数据流数量相同，但是污点数量不同，工具则会认为网站中存在数据流防御措施。数据流防御措施有两种类别，分别对应上文提到的两种不同污点类型：1)值污点清除：网站会将原型对象污染的输入进行统一的处理，如将小写字母统统转化为大写，这样"__proto__"会变成"__PROTO__"，污点就被清除了，后续也就无法获取原型对象并造成污染；2)对象污点清除：这种方法通过给对象污点赋其他的值来清除对象污点，比如将一个对象污点赋值为空对象{}。
实验评估
本文的实验回答以下几个方面的问题：
1.工具发现了哪些零日原型污染漏洞和后果？
工具发现了2738个存在原型污染漏洞的域名，其中包含2917个可利用的原型污染漏洞：185个漏洞已修复，6个已确认，2个已修补但仍存在问题。此外，其中有1217个域名中的1322个漏洞容易遭到攻击，包括 XSS、cookie 操控和 URL 操控。本文通过案例研究发现，原型污染的补丁需要仔细检查：在一个真实案例的研究中，作者发现因为存在多个路径的原型对象查找，打了补丁的JavaScript 代码仍然容易受到攻击。此外，本文还发现出来Object.prototype，其他原型对象，如HTMLIFrameElement.prototype和HTMLDivElement.prototype也可能被污染。
2.本文工具与检测原型污染的最新技术相比如何？
本文工具在检测真实网站中的客户端原型污染漏洞方面明显优于已有工具ObjLupAnsys。具体而言，就检测正确的漏洞而言，本文工具能够检测到2738个易受攻击的域名，而ObjLupAnsys只能检测4个。
3.本文工具性能开销如何？
本文做了对比实验，分别用本工具修改后的浏览器、先前工作修改后的浏览器，以及未经修改的浏览器作对比，比较加载页面的时间。与先前工作的工具相比，本文工具多出了13.4% 的额外中位性能开销，原因是本文工具不仅像以前的工作一样传播值污点，而且还传播对象污点。考虑到本文对一百万个网站的分析结果很不错，这些开销对于漏洞检测工具来说是合理的。
4.工具的漏报情况怎么样？
本文统计了工具两方面检测的漏报情况，分别是a)样本存在原型污染漏洞，以及b)如果样本存在原型污染漏洞，其容易受到XSS攻击的情况。结果如下图所示，工具在为原型污染漏洞检测方面引入了9.5%的漏报，在XSS漏洞利用检测方面引入了20.9%的漏报。
5.工具在动态分析目标代码时的代码覆盖率情况如何？
本文在两个测试集上测试了代码覆盖率情况，分别是来自Github上的43个有着XSS漏洞的代码数据集以及随机挑选的现实世界中的50个存在原型污染漏洞的网站。下图分别为存在漏洞的JavaScript文件中代码覆盖率的累积分布函数图以及代码覆盖率提升的累积分布图：
从图中可以得知，输入/利用生成模块在一定程度上提高了易受攻击的JavaScript文件的代码覆盖率，但是该方法的主要优势是为先前触发的漏洞代码生成利用漏洞的输入，而不是发现新的代码分支。
6.现实世界的网站是如何防范原型对象污染漏洞的？
作者对现实世界中的网站对抗原型对象污染漏洞的方式做了统计，如下表所示。可以看到，最常用的对抗方式是数据流防御措施中的对象清除方法。
总结
原型污染是一种相对较新的漏洞类型。但是研究和检测服务器端原型污染方面有几项工作因其自身缺陷尚且不能很好地用于客户端原型污染漏洞以及其后果的检测。本文工作通过分析联合污点流以及基于缺失属性查找的输入生成方法实现了这是对客户端原型污染漏洞的大规模评估，并且作者已经负责任地向网站所有者报告了所有发现的零日漏洞。
Q&A
Q1:先前的工作或者文章有哪些不足？
先前的工作或者文章要么只是研究了如何检测服务器端的原型污染漏洞；要么只是通过人工分析的方法展示了原型污染漏洞的一些可能的后果，并不能实现大规模检测。
Q2：先前的学术研究中检测原型污染漏洞的方法不能直接用在检测客户端漏洞上，文中具体讲了哪些原因？
ObjLupAnsys不能用于大规模分析，因为“抽象解释”会导致路径和对象爆炸问题；DAPP的FP过高，且漏洞是否真实可利用需要以来人工检测；Arteau依赖于一组给NodeJS包的预定义的输入，而客户端的输入相对多样化，包括message、url、cookie等等，难以做到预定义，其方法并不适用。
Q3:工具中对污点流分析的过程中，涉及到两种不同的污点类型，它们具体有什么区别？
分别是值污点Value Taint和对象污点Object Taint。
首先是概念上的不同：值污点表示攻击者可以直接控制一个变量的值；对象污点类似于一种指针污点，表示当前这个指针可以被攻击者控制，从而指向一个原型对象，比如obj[prop]，这个对象查找操作，如果prop是一个值污点，其返回的结果就是一个对象污点。
其次是传播方式上的不同：Value Taint的传播基于普通的Def/Use分析，如String.concat()以及slice()等操作，如果有参数是Value Taint，会导致执行结果也是Value Taint；而Object Taint的传播方式包括两种，一个是lookup操作，如obj[prop]，如果prop是value taint，这个操作的结果是一个object taint，以及一个对象污点的别名变量也是对象污点。
Q4：文中提到了客户端原型污染的后果，具体有哪些？
XSS（跨站脚本攻击）、存储（缓存）操控、URL操控（可能进一步造成钓鱼攻击）
Q5：文中提到的获取一个对象的原型对象的两种方式？
obj.__proto__，以及obj.constructor.prototype（等价于obj["__proto__"]，以及obj["constructor"]["prototype"]），当只有一条Object Taint Flow的时候，用第一种方式，否则用第二种。
Q6：文中提到的数据流防御措施包括哪两种？
a）值污点清理，将原型污染操作转化为一种无害行为，比如将属性名做大写处理，__proto__变为大写__PROTO__；
b）对象污点清理，如在原型链污染点之前将其他对象赋值给对象污点
文案：HN
排版：YST
戳“阅读原文”即可查看论文原文哦~
复旦白泽战队
一个有情怀的安全团队
还没有关注复旦白泽战队？
公众号、知乎、微博搜索：复旦白泽战队也能找到我们哦~
原文始发于微信公众号（复旦白泽战队）：白泽带你读论文 | Probe the Proto
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论