如何手动修复npm漏洞？

Question

如何手动修复npm漏洞？

140

当我运行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时，它会给我一个类似于以下表格的列表：

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ 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                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

在这个例子中，链接页面的修复部分说“更新到4.17.5或更高版本”。然而，在/node_modules/browser-sync/package.json中有以下几行：

"devDependencies": {
    "lodash-cli": "4.17.5",
}

现在不再有lodash的依赖关系，因此它应该已经是v4.17.5。我还检查了/node_modules/lodash/lodash.json文件，其中包含var VERSION ='4.17.10';一行。在/node_modules/lodash/package.json中有这些行：

  "_from": "lodash@^4.17.4",
  "_id": "lodash@4.17.10",

我相信版本显示在“_id”而不是“_from”，因此版本是正确的，但漏洞仍然出现在审核列表中。

我还是新手在node.js中，这些消息让我感到困惑。有没有办法手动修复或摆脱那些我无法处理的消息？

- Jakupov

这个回答解决了你的问题吗？如何修复 package-lock.json 中未在 package.json 中列出的易受攻击的 npm 包？ - JBallin

7个回答

19

如果您确定要跳过审核，可以通过追加 --no-audit 来实现。

 npm install --no-audit

来源：文档

情况可能是:

误报
在您的特定环境中没有影响的漏洞
存在于您没有使用的代码部分的漏洞

误报进一步阅读

错误的上下文进一步阅读

更新 2022

或者您可以使用 Better NPM audit 来微调审核过程。

- Tjad Clark

10

'npm audit fix' 会增加 package.json 中依赖项的版本，可能导致代码出现问题。更好的方法是打开 package-lock.json，并将依赖/子依赖版本更新到所需的版本。在存储库中保留 package-lock.json。

有时漏洞来自开发包，在这种情况下忽略这些漏洞，因为它们不会在生产中被拾取。

- nik

将开发包从package.json文件本身添加/更新怎么样？这种方法有什么不方便之处吗？ https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file - carloswm85

只更新 package-lock，而不更新 package.json 有什么意义？这样做如何修复问题？ - connected_user

6

可以尝试使用以下命令：

npm audit fix --force --production

这可能解决您的问题。

- code chan

2

它将强制安装具有破坏性更改的软件包版本。 - Viraj Singh

1

你可以使用强制选项来执行修复，命令为npm audit fix --force。

- 40Sherrin

1

然而，这将包括破坏性变更。 - Monstar

2

有时也不总是有效的。例如，我收到了以下信息：“从172个贡献者添加了555个软件包，删除了350个软件包，并在52.021秒内更新了1500个软件包修复了2057个扫描软件包中的22个漏洞 22个漏洞需要手动审查，无法更新。” - Konstantinos

0

真正的安全漏洞（和曝光）在安全意义上具有其专属的CVE和/或GHSA ID。可以使用诸如Anchore Grype、Trivy或Snyk等多种广泛覆盖的安全扫描工具来扫描JavaScript包中的此类漏洞，这些工具可以指示出问题的`package.json`文件的路径，并显示已安装包的版本以及CVE/GHSA ID。这些扫描程序也可应用于在允许部署之前对整个Docker容器执行自动化扫描（作为例如Jenkins流水线的一部分）。

手动修复 JS 包中的 CVE（如果 `npm audit fix` 无法自动完成）包括通过升级来修复，例如使用 `npm i @`，如果安全补丁已经存在（可以通过 `npm outdated ` 进行验证），可能需要多次升级（在所有嵌套级别），或者在补丁可用之前对 CVE 编号和包组合进行白名单处理（或者如果它属于“不修复”类别）。偶尔需要升级 `node` 自身，如果 `node` 二进制文件受到影响，可以使用 `nvm install && nvm alias default ` 进行升级。

- mirekphd

-8

我尝试了这个方法，对我有效。请运行以下命令：

> npm audit fix    
> npm set audit false

- Anya

2

请添加更多细节以扩展您的答案，例如工作代码或文档引用。 - Community

需要更多信息。 - curveball

关闭审计并不能修复漏洞 - 你停止看到漏洞，是因为你关闭了审计。问题是如何手动修复它们，而不是隐藏它们。 - Tobi Teps

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Estus Flask · Accepted Answer

devDependencies 中的 lodash-cli 不会影响 browser-sync 在您的项目中的工作方式，当一个包被安装为依赖项时，devDependencies 会被忽略。

audit 报告显示的是 easy-extender 具有 lodash 依赖项：

browser-sync > easy-extender > lodash

它依赖于Lodash 3, 但该问题已在Lodash 4中得到解决。该问题可以通过fork easy-extender，更新并安装它来修复，而不是使用NPM公共注册表中的软件包。但这个依赖关系没有真正的问题。

audit报告的重要性应该手动评估。即使嵌套的依赖关系存在安全风险，这也不意味着引入此风险的功能被使用。这也不意味着即使它被使用，由于使用方式的原因，它会引入实际风险。

browser-sync是一种开发工具，在生产中不使用，因此几乎没有场景可以利用其漏洞。而原型污染根本不是漏洞，只是一个提示，表明软件包没有遵循良好的实践，可以忽略。

通常，修复报告的漏洞的方法如下：

进行合理性检查
如果是真正的问题，请检查易受攻击软件包的存储库是否存在问题和PRs
如果没有，请提交问题
在NPM发布之前，将存储库分支或使用现有的PR作为git依赖项进行修复
在嵌套依赖关系的情况下，在几个嵌套级别上执行此操作

大多数情况下，人们预计您不会超越合理检查，唯一的问题是“漏洞”混乱了审计报告并隐藏了真正的漏洞。 patch-package 可以帮助修补嵌套依赖项，但这不会影响报告。

在 Yarn 1 和 2 中，可以通过 resolutions field 强制使用特定的嵌套依赖版本，这将影响审计报告。未来可能可以在 NPM 中本地执行此操作。目前，在 NPM 中的替代方法是第三方 npm-force-resolutions 实用程序，它提供较少的控制，目前它强制解决了所有依赖项，而不是特定的依赖项。

请注意，通过强制依赖项使用其未设计用于的嵌套依赖项，它可能随时变得不可用。这尤其适用于 npm-force-resolutions，它是一个笨重的工具，可能会同时影响许多嵌套依赖项。