前端安全——最新，网络安全高级面试题及答案

最新推荐文章于 2024-05-06 13:41:34 发布

2401_84254057

最新推荐文章于 2024-05-06 13:41:34 发布

阅读量943

点赞数 23

分类专栏： 2024年程序员学习文章标签：安全前端 web安全

本文链接：https://blog.csdn.net/2401_84254057/article/details/137621284

版权

2024年程序员学习专栏收录该内容

108 篇文章 0 订阅

订阅专栏

1. 漏洞复现

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

const payload = ‘{“constructor”: {“prototype”: {“lodash”: true}}}’
_.defaultsDeep({}, JSON.parse(payload))
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**库中的函数 defaultsDeep 可以修改 Object.prototype 的属性。JavaScript 在读取对象中的某个属性时，如果查找不到就会去其原型链上查找。试想一下，如果被修改的属性是 toString 方法，例如：

const payload = ‘{“constructor”: {“prototype”: {“toString”: true}}}’

_.defaultsDeep({}, JSON.parse(payload))

payload又为用户输入的数据，那么，在调用Object.prototype.toString 时就会非常不安全了。

lodash原型污染漏洞出现在Lodash:4.17.12版本以下，我们可以来看下，依赖源码出现漏洞的地方：

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

3. 修复漏洞

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

tips:以下操作前请做好项目备份

3.1 直接版本升级解决

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

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

3.2 子依赖lodash问题解决

上面的情况是最好的情况，也是最简单的情况，但是实际上，我们遇到的问题可能比这个复杂的多。因为lz发现，本地前端项目package.json根本就没有引入lodash依赖。

这种情况下，上面那种方法就很明显行不通了，版本都没引入更遑论改版本了，那么，问题来了。既然没有引入lodash.js，那么**_.defaultsDeep方法又是哪来的呢。经过我的排查，终于发现，在package-lock.json文件下，显示了引入了多个不同版本的lodash，正如我前面所说，lodash 作为一款非常流行的npm库，提供了很多的方法。所以也是很多第三方库的子依赖。我不引用它，不代表第三方库不引用它。而且从全局搜索来看，引入的地方还挺多。因此也没法一个个改。经过学习了解，发现可以通过resolutions**指定子依赖版本。