前端安全——最新：lodash原型漏洞从发现到修复全过程 ...

前端安全——最新：lodash原型漏洞从发现到修复全过程

1. 漏洞复现

1. 现在很多系统的前端都是基于vue和react框架的，所以就肯定少不了引入各种依赖，而lodash作为一款非常流行的npm库，每月的下载量超过8000万次。可以说是使用的十分广泛了。所以可以想象，当lodash这个漏洞出现时，标志着有多少项目存在被攻击的风险。而检测的方法也很简单，在你的前端控制台，输入下面代码：

复制代码

1. const payload = '{"constructor": {"prototype": {"lodash": true}}}'
2. _.defaultsDeep({}, JSON.parse(payload))
3. if({}.lodash === true){ alert("Bad news :(\nYou're (still) vulnerable to Prototype Pollution") } else { alert("All Good! :)\nYou're NOT vulnerable (anymore) to Prototype Pollution") }

复制代码

如果出现如下弹窗，就说明没有漏洞。lodash版本是最新的，已经把漏洞修复了。如果不是，那么恭喜你，中奖了~继续往下看吧。

2. 漏洞原理剖析

   通俗来讲：攻击者可以通过lodash的函数覆盖或污染JavaScript对象的原型（prototype）
  例如：通过lodash库中的函数defaultDeep可以修改Object.prototype的属性。JavaScript在读取对象中的某个属性时，如果查找不到就会去其原型链上查找。试想一下，如果被修改的属性时toString方法，例如：

1. const payload = '{"constructor": {"prototype": {"toString": true}}}'
2. _.defaultsDeep({}, JSON.parse(payload))

复制代码

payload又为用户输入的数据，那么，在调用Object.prototype.toString时就会非常不安全了。
lodash原型污染漏洞出现在Lodash:4.17.12版本以下，我们可以来看下依赖源码出现漏洞的地方：

结论：实现了一个safeGet的函数来避免获取原型上的值。但是没有考虑到构造方法constructor的环境，因此，在lodash连夜发版修复方法：

3. 修复漏洞

1. 在理解了漏洞如何出现的情况下，下面我们要做的就是修复漏洞。到这里，有些人可能就明白了，既然原型污染漏洞是由于lodash版本过低导致的，那我直接将package.json中的lodash版本库改为最新的`4.17.21`不就行了。别急，下面循序渐进，由浅入深的理解并修复这个漏洞。

复制代码

  tips：以下操纵前请做好项目备份

  3.1 直接版本升级办理

1. 假如你的项目很简单，并且package.json也很直观的显示了引入的lodash版本低于4.17.12，那么大概率直接修改版本就解决了。如果解决不了，可以试试修改版本号后。

复制代码

删除node_modules和package-lock.json，重新npm install一下

3.2 子依赖lodash问题办理

1. 上面的情况是最好的情况，也是最简单的情况，但是实际上，我们遇到的问题可能比这个复杂的多。因为我发现，本地前端项目package.json更新了lodash版本后，然后再控制台进行测试验证，还是会出现lodash版本低的情况。
2. 

复制代码

这种环境下，上面那种方法就很显着行不通了，版本更新了，还是存在问题，那么问题来了，这个_.defaultDeep方法到底是那里来的呢。颠末排查，终于发现，再package-lock.json文件下，显示了引入多个不同版本的lodash，正如前面所说，lodash作为一款非常流行的npm库，提供了很多方法。以是也是很多第三方库的子依赖。我在package.json中升级版本，不代表我升级了第三方库引用它的版本。而且从全局搜索来看，引入的地方还挺多。因此也没办法一个一个改。颠末学习相识，发现可以通过resolutes指定子依赖版本。

在npm中，resolutions字段通常用于办理依赖版本冲突的问题。当你利用resolutes字段时，你可以轻质指定某个依赖包的版本，以确保项目中利用的依赖包版本符合你的要求。

1. {
2.   "name": "my-project",
3.   "version": "1.0.0",
4.    "scripts": {
5.         "serve": "vue-cli-service serve",
6.         "build": "vue-cli-service build",
7.         "preinstall": "npx force-resolutions"
9.     },
10.   "dependencies": {
11.     "element-ui": "^2.15.8",
12.   },
13.   "resolutions": {
14.         "lodash": "4.17.21"
15.     },
16.   "overrides": {
17.         "**/lodash": "4.17.21"
18.   },
19. }

复制代码

overrides设置为resolutions的替补，要求npm 8以上。script下新增一条下令：

1. "preinstall": "npx force-resolutions"

复制代码

这条下令通常是为了在安装依赖包之前强制执行 force-resolutions 工具，以确保 resolutions 字段中指定的依赖版本得到精确安装。正常环境下，npm install的时候就会自动检测并执行了。
执行完之后，可以通过下面下令查看子依赖是否都已指定版本成功
npm list lodash

3.3 追更溯源办理

1. 不出意外的话，上面两种方法都用过之后，应该可能或许大概也许就解决这个漏洞了吧，但是凡是总有例外，很明显。我就是那个万里挑一的中奖者。我检测发现问题依旧存在，在这里，我得内心是抓狂崩溃的。明明什么方法都用过了，为什么还会报错。
2. 我直接在控制查看这个方法的调用源头：

复制代码

   输入_.defaultDeep回车后，出现一段代码，双击进入就可以查看哪个文件引用了
  等等，element-ui什么时候引入了lodash.js，再到package-lock.json中看，它的子依赖根本就没有引入lodash依赖啊。但是在node_modules一查，发现lodash.js文件确实存在，而此中最关键方法safeGet方法也确实存在漏洞。心里感叹终于找到原因了。

不信邪，还特意看了一下官方依赖，果然不出所料，你个老⑥

关键element-ui这里2.15.14版本还是最新的，想想挺可怕的，以是最后的办理方法就是更新element-ui版本到2.15.8，由于此版本没有引入lodash.js。
3.4 不出不测的话又有不测

更新element-ui版本后，测试发现还报错；瓦解的大哭，再细致查看项目，好家伙，发现竟然当地引入了一个lodash.js文件，此时我摸了一把泪，抱着盼望更新里面的内容版本，然后测试，终于可以了，心里瞬间轻松了