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

前端项目扫描漏洞整改的解决方案，附带部分漏洞的解决方法。

news 来源：原创 2025/5/14 12:01:26

天崩开局

最近项目开始了漏洞扫描，于是乎
在这里插入图片描述
哎嘿嘿。。。

在这里插入图片描述
我直接彻底疯狂！！！！
我真的受不了了，这破班谁爱上谁上！依赖开发的锅，为什么要我来背。
在这里点名批评一下 inflight，7个版本全被 deprecated 掉了，关键是这下载量？？？

在这里插入图片描述
OK，吐槽归吐槽，问题还是要解决的。

解决方案

大部分漏洞，只需要更新版本就能够解决，但是有很多依赖都是子依赖，我们直接修改锁文件的话，重新安装的时候会被父依赖的依赖源给覆盖掉。

方案一： node_modules文件夹中找出父依赖的依赖文件，去手动修改对应的版本号。（难我天 ^ _ ^）
我一开始的确是这么做的，但是这方法很大缺陷。

node_modules文件夹中文件茫茫多，漏洞少的话还好说，多的话任务量就巨大了。
需要安装两遍依赖，才能完成子依赖的安装。
还有一个致命缺陷，如果重新部署项目，那么以上这些全部白费，必须把修改的 node_modules文件夹一起打包给仓库。

所以这个方案不推荐。

方案二： package.json 配置项。

“scripts” 中添加配置 "preinstall": "npx force-resolutions"，然后在 "dependencies" 同级下新加一个 "resolutions" 配置项。

npm run preinstall // 替换掉锁文件中的所有对应依赖版本

比如说，async-validator 依赖的无漏洞版本是 4.0.7 及以上，那我们就可以有如下配置：

package.json

{"scripts": {"dev": "vue-cli-service serve","preinstall": "npx force-resolutions"},"dependencies": {"axios": "1.7.4"...},"devDependencies": {"babel-eslint": "10.1.0"...},"resolutions": {"async-validator": "4.0.8","inflight": "2.0.6"}
}

注意：

如果是第一次使用，npm run preinstall 的时候会提示你安装一个 resolutions 包，直接 Y 安装就行。

使用该命令的前提是已经生成了锁文件 package-lock.json，然后它会去根据 resolutions 中的配置去替换掉锁文件中所有对应依赖的版本。

提示没有锁文件。

完成替换。
执行 npm i 命令时，会默认先执行 npm run preinstall 命令。如果是新部署的项目，第一遍 npm i 是安装 dependencies 和 devDependencies 中的所有依赖，第二遍 npm i 就会完成版本替换，并且安装替换后的依赖版本。
所以，我们可以省略 npm run preinstall，直接执行两遍 npm i 命令。

这个方案不用去 node_module 文件夹中去修改子依赖版本号，省去了相当一部分工作量。

举例

这里列举一些依赖的修补方法。

对于正常有无漏洞版本的依赖，两遍安装基本就能解决问题。

async-validator-1.8.5
如果你用了 Element-UI 的表单校验功能，它对应的一个依赖 async-validator-1.8.5 就存在漏洞。

async-validator 是异步形式的验证器。由于rule.ts 和index.js 文件中的 type() 函数使用不安全的正则表达式进行验证，因此该包的受影响版本容易受到正则表达式拒绝服务 (ReDoS) 的攻击用户提供的 URL。远程攻击者可以通过提供利用大量字符的 URL 来利用此漏洞。

对于这个漏洞，作者在 4.0.4 版本中使用了 “url-regex”: “^5.0.0” 来替换了 type() 函数的正则验证，但很不幸的是，这个依赖本身也存在漏洞。。。（这里就不展开多说了）
然后作者在 4.0.7 版本中摒弃了这个依赖，并修复了之前存在的漏洞，所以这个依赖只需要 升级到 4.0.7 及以上版本 就可以了。ElementPlus 中的表单验证就是使用最新版本的 async-validator: 4.2.5，并且 4.0.7 及以上的版本也可以兼容 Element-UI 中的表单验证，之下的好些版本会让 Element-UI 的表单校验功能失效。（拦截正常，但是红色警告文本弹不出来）

对于一些天坑依赖，我们就需要使用一些特别手段了。

inflight-1.0.4
修改漏洞的时候，这个依赖应该都绕不过去吧！

当某些资源在使用后未正确释放时，此软件包的受影响版本很容易受到有效生命周期后资源丢失释放的影响。

这个依赖主要为正在进行的请求添加回调，以避免异步重复。这是一个非常常用的功能，以至于大量的依赖都中使用了它！

正如我上面所吐槽的，该依赖全版本都存在漏洞，而作者也已经放弃更新，并宣布弃用该依赖。
对于 inflight 这种的天坑依赖，让我去重构它的代码是不可能的。那只能从扫描软件上下功夫了，我们可以换一个不存在的版本，这样就可以绕过扫描软件的漏洞库，从而实现最终“修复”。
我是先正常安装所有依赖，然后等到所有的可修复漏洞修改完后，我们再在 resolutions 中添加 inflight: 2.0.6 ，然后执行 npm run preinstall ，之后注意不要再执行 npm i 了，因为这个时候会报错，直接打包扫描就行。

其实对于所有有漏洞的依赖来说，都可以通过这种方法修复。但这种修复方式是迫不得已的一种选择，能不用尽量别用。

总结

对于与我来说，修改漏洞这个东西，如果有无漏洞版本那就好说，如果没有的话，说好听点是修改，说白了就是掩盖，好多都是掩耳盗铃式修改，但是有好多漏洞确实是矫枉过正，所以我这里也只是应付一下。
如果有什么更好的方案，欢迎大佬们指教。

最后，再次对 inflight 点名批评！

参考：修改依赖包下的子依赖版本，前端项目安全扫描出来的漏洞——解决过程

天崩开局

解决方案

举例

总结

相关文章：