文章总结： 本文详细拆解了原型污染漏洞的实战挖掘过程，作者通过逐步试探发现目标网站对proto等关键词进行了黑名单过滤，但该过滤仅单层处理。通过构造proprototo等变形字符串成功绕过过滤实现Object.prototype污染，并结合页面中未设置transport_url属性的configgadget，最终通过污染注入XSSpayload完成漏洞利用。 综合评分： 85 文章分类： web安全,漏洞分析,实战经验

原型污染赏金实战：Object.prototype 纹丝不动？绕过黑名单拿下奖金

原创

升斗安全XiuXiu 升斗安全XiuXiu

升斗安全

2026年5月14日 08:15 广东

在小说阅读器读本章

去阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

你是否也遇到过这样的情况：明明找到了疑似有问题的 JavaScript 代码，各种方法都试了，Object.prototype 就是纹丝不动，怎么都污染不进去？

别着急，今天咱们就来完整拆解一次“原型污染”的挖掘过程，看看老猎人们是怎么一步步死磕，最后把看似堵死的路走通的。

先找个地方下手

打开目标网站，我们先做一个最朴素的试探。在浏览器地址栏的 URL 后面加上查询参数，试着往 Object.prototype 里塞点东西，比如：

/?__proto__.foo=bar

回车之后，打开开发者工具，切到控制台，直接敲 Object.prototype，看看返回的对象里有没有长出我们期待的 foo 属性。

很遗憾，这次什么都没发生，干净得就像什么都没加过。

不灰心，换几种常见的污染向量继续试：

/?__proto__[foo]=bar

/?constructor.prototype.foo=bar

结果一样，对象还是不搭理我们。看来硬塞是行不通了，这条路对方明显做了防护。

去看看“守门员”长什么样

这时就别在地址栏里盲目撞了，得去翻翻目标站点加载的 JavaScript 文件。切到开发者工具的“源代码”面板，一个个脚本看过去。有意思的地方通常藏在这些小工具文件里。

很快，在 deparamSanitized.js 里，我们发现了一个关键信息：它用到了 searchLoggerFiltered.js 里定义的一个 sanitizeKey() 函数，试图通过黑名单把危险的属性键过滤掉。

但紧接着发现一个细节——这个过滤函数并不是递归处理的，它只做了一层“消毒”。也就是说，我们只要想办法在过滤前和过滤后，让字符串“变形”一下，让危险键残留下来，游戏就成功一半了。

绕过去，把属性种进去

既然知道了过滤的弱点，思路就清晰了：在黑名单关键词里掺杂一些字符，让它被“清洗”后恰好拼出我们想要的危险键。

回到地址栏，开始尝试这种“拆开再拼上”的套路：

/?__pro__proto__to__[foo]=bar

/?__pro__proto__to__.foo=bar

/?constconstructorructor[protoprototypetype][foo]=bar

/?constconstructorructor.protoprototypetype.foo=bar

每加完一个版本，就回到控制台重新看 Object.prototype。当看到返回的对象里，终于多了一个 foo 属性，而且值是我们给的 bar 时，你就可以松口气了“原型污染源”找到了，那道看似严密的键过滤也被我们绕了过去。

有了源头，还得找能用它的“零件”

光污染进去不行，得让它能对页面产生实际影响。这就要找代码里一个愿意“配合”我们的 gadget。

继续翻那些 JavaScript 文件，在 searchLogger.js 里注意到一段逻辑：它里面有个 config 对象，如果 config 的 transport_url 属性存在，代码就会动态创建一个