技能介绍

要解决的具体问题

原型污染的根源通常不是某个 API 的“设计缺陷”，而是属性合并、递归赋值或解析库把外部输入当成可信结构。一旦攻击者能让 __proto__、constructor.prototype 这类键参与合并或赋值，影响就可能扩散到整个进程内共享 Object.prototype 的对象，而不是只停留在当前请求或页面路由里。

当目标代码存在以下特征时，风险尤其明显：深层合并、递归 assign、JSON.parse 后紧跟 Object.assign、URL 查询参数被展开成嵌套对象、使用 lodash.merge、deep-extend、hoek.applyToDefaults，或在服务端用 qs 一类解析器处理输入。此时普通输入校验很难覆盖所有中间路径，需要把解析行为当作攻击面来观察。

技能如何工作

Prototype Pollution Attack Playbook 把利用过程拆成输入面排序、探测、接收点确认和链式利用四层。它先指导优先关注高风险解析路径：客户端输入能反射到 DOM 或框架路由时，结合 alert(1) / console 观察全局属性是否异常；服务端 JSON / form 场景则在发送后检查无关后续响应的 header、状态码、JSON 间距变化，或确认应用是否读取了 Object.prototype.polluted。

在接收点识别上，技能聚焦具体函数和调用模式，而不是泛泛列举框架。若目标使用 lodash.merge、deep-extend、hoek.applyToDefaults，或存在 qs / query-string 配置项，优先级会被提升；确认污染后，再沿 EJS、Timelion 类模式、child_process / NODE_OPTIONS 等可被污染后触发的 sink 做链式分析。

适用边界与注意点

使用该手册前应已经理解对象展开（object spread）和原型继承机制，否则容易把“能改 Object.prototype”误当成完整利用。它更偏向攻击侧视角：帮助确认解析器行为和 post-pollution sink，而不是通用漏洞扫描或防御加固方案。

对真实目标使用时，需要区分“可观测污染”和“可控属性”：日志中出现异常值，不代表一定能到达 child_process 或模板渲染逻辑。针对 __proto__ 与 constructor.prototype 的探测路径也要分别验证，因为不同解析库和 merge 实现对键名处理并不完全一致。