问题描述
当我运行 npm install 时，它说 found 33 个漏洞(2 个低，31 个中等)运行 `npm audit fix` 来修复它们，或者运行 `npm audit` 获取详细信息.
When I run npm install it says found 33 vulnerabilities (2 low, 31 moderate) run `npm audit fix` to fix them, or `npm audit` for details.
然而，npm audit fix 在 11 秒内输出最新修复了 24653 个扫描包中 33 个漏洞中的 0 个33个漏洞需要人工审核，无法更新
However, npm audit fix outputs up to date in 11sfixed 0 of 33 vulnerabilities in 24653 scanned packages 33 vulnerabilities required manual review and could not be updated
那个 review 是否意味着它不应该由用户修复?
Does that review mean it is not supposed to be fixed by user?
当我运行 npm audit 时，它为我提供了表列表，类似于:
When I run npm audit it gives me list of tables, similar to this:
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ 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 中有几行:
In this example remediation section of linked page says Update to version 4.17.5 or later.. However, in /node_modules/browser-sync/package.json there are lines:
"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 中有这些行:
and no more lodash dependencies. So it should already be v4.17.5. I also checked /node_modules/lodash/lodash.json which has var VERSION = '4.17.10'; line. In /node_modules/lodash/package.json there are these lines:
"_from": "lodash@^4.17.4",
"_id": "[email protected]",
我相信_id"中显示的版本，而不是_from"中，所以版本是正确的，但漏洞仍然出现在审核列表中.
I believe that version shown in "_id", not in "_from", so versions are correct but vulnerability still appear in audit list.
我还是 node.js 的新手，这些消息让我很困惑.有什么办法可以手动修复它或摆脱这些消息，我无能为力吗?
I'm still new in node.js and those messages confuses me a lot. Is there any way to fix it manually or get rid of those messages, I can't do anything with?
推荐答案
lodash-cli in devDependencies 不影响 browser-sync> 在您的项目中运行，devDependencies 在安装包作为依赖项时被忽略.
lodash-cli in devDependencies doesn't affect how browser-sync works in your project, devDependencies are ignored when a package is installed as a dependency.
audit 报告说的是 easy-extender 具有 lodash 依赖:
What audit report says is that it's easy-extender that has lodash dependency:
browser-sync > easy-extender > lodash
它依赖于 Lodash 3，而该问题已在 Lodash 4 中修复.该问题可以通过分叉 easy-extender、更新并安装它而不是来自 NPM 公共注册表的包来解决.但是这种依赖并没有真正的问题.
It depends on Lodash 3, while the problem was fixed in Lodash 4. The problem could be fixed by forking easy-extender, updating it and installing it instead of the package from NPM public registry. But there is no real problem with this dependency.
audit 报告重要性应手动评估.即使嵌套依赖具有安全风险，这并不意味着使用了引入此风险的功能.这也并不意味着即使使用它，也会由于使用方式而带来真正的风险.
audit report importance should be evaluated manually. Even if nested dependency has security risk, this doesn't mean that a feature that introduces this risk was used. This also doesn't mean that even if it's used, it introduces real risk due to how it's used.
browser-sync 是未在生产中使用的开发工具，可以利用其漏洞的场景并不多.而且Prototype Pollution根本不是漏洞，只是一个包没有遵循良好实践的通知，它可以被忽略.
browser-sync is development tool that isn't used in production, there are not so many scenarios where its vulnerabilities could be exploited. And Prototype Pollution isn't a vulnerability at all, just a notice that a package doesn't follow good practices, it can be ignored.
通常，这是修复报告漏洞的方法:
Generally, this is the way to fix reported vulnerabilities:
- 进行健全性检查
- 如果这是一个真正的问题，请检查易受攻击包的存储库是否存在问题和 PR
- 如果没有，请提交问题
- 分叉存储库或使用现有 PR 作为 git 依赖项，直到它在 NPM 版本中得到修复
- 对于嵌套依赖项，请在多个嵌套级别执行此操作
- Do a sanity check
- In case it's a real problem, check the repository of vulnerable package for existing issues and PRs
- In case there's none, submit an issue
- Fork a repository or use use existing PR as git dependency until it's fixed in NPM release
- In case of nested dependencies, do this at several levels of nesting
大多数情况下，预计您不会超越健全性检查，唯一的问题是漏洞"杂乱的审计报告并隐藏真正的漏洞.
Most times it's expected that you won't advance beyond a sanity check, and the only problem is that a "vulnerability" clutters audit report and conceals real vulnerabilities.
patch-package 可以帮助修补嵌套依赖项-place 但这不会影响报告.
patch-package can help to patch nested dependencies in-place but this won't affect the report.
可以使用 resolutions 字段，这会影响审计报告.将来可能会在 NPM 中原生执行此操作.目前 NPM 中的替代方案是第三方 npm-force-resolutions 提供较少控制的实用程序，目前它强制解决所有依赖项，不是特定的.
It's possible to force specific dependency version in nested dependency in Yarn 1 and 2 with resolutions field, this will affect audit report. It may be possible to do this natively in NPM in future. Currently the alternative in NPM is third-party npm-force-resolutions utility that gives less control, currently it forces a resolution for all dependencies, not a specific one.
请注意，通过强制依赖项使用它不适合使用的嵌套依赖项，它随时可能被破坏.这尤其适用于 npm-force-resolutions，它是一个生硬的工具，可以同时影响许多嵌套的依赖项.
Notice that by forcing a dependency to use nested dependencies it wasn't designed to work with, it can become broken at any moment. This especially applies to npm-force-resolutions, which is a blunt tool and can affect many nested dependencies at once.
这篇关于如何手动修复 npm 漏洞?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！