如何手动修复npm漏洞?

Jak*_*pov 43 node.js npm npm-audit

我跑的npm install时候说found 33 vulnerabilities (2 low, 31 moderate) run `npm audit fix` to fix them, or `npm audit` for details.

但是,npm audit fix产出up to date in 11s fixed 0 of 33 vulnerabilities in 24653 scanned packages 33 vulnerabilities required manual review and could not be updated

这是否review意味着它不应由用户修复?

当我运行npm audit它时,给我一个表的列表,类似于Update to version 4.17.5 or later.

在此示例中,链接页面的修复部分说/node_modules/browser-sync/package.json.但是,/node_modules/lodash/lodash.json有以下几行:

????????????????????????????????????????????????????????????????????????????????
? Low           ? Prototype Pollution                                          ?
????????????????????????????????????????????????????????????????????????????????
? Package       ? lodash                                                       ?
????????????????????????????????????????????????????????????????????????????????
? Patched in    ? >=4.17.5                                                     ?
????????????????????????????????????????????????????????????????????????????????
? Dependency of ? browser-sync [dev]                                           ?
????????????????????????????????????????????????????????????????????????????????
? Path          ? browser-sync > easy-extender > lodash                        ?
????????????????????????????????????????????????????????????????????????????????
? More info     ? https://nodesecurity.io/advisories/577                       ?
????????????????????????????????????????????????????????????????????????????????
Run Code Online (Sandbox Code Playgroud)

而且没有更多的lodash依赖.所以它应该已经是v4.17.5.我还检查了var VERSION = '4.17.10';哪一/node_modules/lodash/package.json行.在npm install有这些线路:

"devDependencies": {
    "lodash-cli": "4.17.5",
}
Run Code Online (Sandbox Code Playgroud)

我认为版本显示在"_id"中,而不是"_from",因此版本是正确的但漏洞仍然出现在审计列表中.

我仍然是node.js的新手,这些消息让我很困惑.有没有办法手动修复它或摆脱这些消息,我不能做任何事情?

Est*_*ask 17

lodash-cliin devDependencies不会影响browser-sync项目的工作方式,devDependencies将软件包作为依赖项安装时将被忽略。

什么audit报告说的是,这是easy-extenderlodash依赖性:

browser-sync > easy-extender > lodash        
Run Code Online (Sandbox Code Playgroud)

取决于Lodash 3,而该问题已在Lodash 4中得到解决。可以通过分叉easy-extender,更新和安装它(而不是NPM公共注册表中的软件包)来解决此问题。但是这种依赖性没有真正的问题。

audit报告重要性应手动评估。即使嵌套的依赖项具有安全风险,也并不意味着已使用引入此风险的功能。这也不意味着即使使用它,也会由于使用方式而带来实际风险。

browser-sync是生产中不使用的开发工具,没有太多可以利用其漏洞的方案。和原型污染是不是所有漏洞,只是一个通知,一包不遵循良好的做法,可以忽略不计。

通常,这是修复报告的漏洞的方法:

  • 进行健全性检查
  • 万一这是一个真正的问题,请检查易受攻击软件包的存储库中是否存在现有问题 PR
  • 如果没有,请提交问题
  • 分叉存储库或使用现有PR作为git依赖项,直到在NPM版本中对其进行修复
  • 如果嵌套了依赖项,请在多个嵌套级别上执行此操作

多数情况下,预计您不会超越健全性检查标准。

patch-package可以帮助就地修补嵌套的依赖关系,但这不会影响audit报告。

  • *但我可以忽略 31 个中等的吗?* - 这就是“健全性检查”的内容,请使用您的判断。你越关注这些报告的实际内容,你就能成为更好的开发人员,在安全方面。*我应该向软件包开发人员发布关于它们的信息吗?* - 您可能应该(至少关闭“审计”),答案回答了这个问题。人们不知何故没有“npm审计”。它们对应用程序造成真正安全问题的可能性非常低,但在不知道它们是什么以及它们如何在您的应用程序中使用的情况下,我无法保证。 (5认同)

Tja*_*ark 12

如果您绝对确定要跳过审核,则可以通过附加 --no-audit 来实现

 npm install --no-audit
Run Code Online (Sandbox Code Playgroud)


nik*_*nik 9

'npm audit fix' 将增加 package.json 中的依赖版本,这可能会导致代码中断。所以更好的方法是打开 package-lock.json 并将依赖/子依赖版本更新为所需版本。在存储库中维护 package-lock.json。

有时漏洞来自开发包,在这种情况下,忽略这些漏洞,因为这些漏洞没有在生产中被发现。


小智 6

用这个

npm 审计修复--force--生产

可能可以解决你的问题

  • 它将强制安装具有重大更改的软件包版本 (2认同)