如何修复package.json中未列出的package-lock.json中的易受攻击的npm包?

Rap*_*117 63 node.js npm package.json package-lock.json

Github告诉我,package-lock.json文件中的依赖项容易受到攻击并且已过时.问题是,如果我这样做,npm install或者npm update都没有更新package-lock.json文件中的依赖项.

我已经做了很多谷歌搜索,以及删除文件和完成npm install.

如果有人能帮忙解决这个问题,我会非常感激.有问题的包是Hoek,我在package.json文件中实际上没有.

提前谢谢了.

Ale*_*ock 25

听起来好像Hoek是你的一个依赖项的依赖项(因此,你的package.json中的一个包需要它来自它自己的package.json).

您已经尝试删除/重新安装和更新项目依赖项而没有成功,因此似乎所涉及的包依赖项具有指定的显式或最大版本.

如果没有看到每个依赖项的package.json,就很难就如何强制更新提出进一步的建议.

编辑: 为了帮助您确定哪些包使用哪些依赖项,您可以使用NPM的ls命令:https://docs.npmjs.com/cli/ls

例如,要查看使用Hoek的软件包: npm ls hoek

编辑2: 正如Ulysse BN正确指出的那样,如果您有NPM版本6或更高版本,您可以使用npm audit fixNPM来尝试为您修复漏洞.

  • 我在另一个包(Growl)中遇到了类似的问题。我猜这是我的package.json中某些内容的某个版本,具体取决于特定的(脆弱的)Growl版本。您的答案是在正确的轨道上,如果您可以共享一条命令来显示“ package.json”中的哪个软件包,取决于哪个依赖于“ package-lock.json”中的脆弱软件包的命令,那么您可能会钉上它。 (2认同)

JBa*_*lin 13

TLDR:使用来更新父包npm i $PARENT_PKG_NAME


诊断

npm audit将同时揭示易受攻击的软件包(请注意,您需要为此使用package-lock.json文件,因此您需要运行npm i),以及它所依赖的软件包(如果适用)。请注意,您还可以npm ls $CHILD_PKG_NAME用来查看其父项依赖项。

快速修复尝试

npm audit fix并且npm audit fix --force值得一试,但有时需要手动完成此修复程序(请参见下文)。

手动修复

父程序包很可能已经修复了它们的依赖关系(您可以通过转到其GitHub并查看最近的提交进行验证,或者只是查看它是否已解决该问题),因此您可以运行npm i $PARENT_PKG_NAME并更新程序包锁.json。

验证修复

现在,您可以通过运行npm audit并确保没有漏洞显示来验证它是否有效。提交您的更改,将其推送到GitHub,刷新您的通知/警报,它们应该消失了!


Uly*_* BN 8

如果您有 npm@6 或更高版本,则可以用于npm audit fix解决安全问题。


jba*_*das 6

自 NPM v8.3.0 (2021-12-09) 起,package.json有一个属性overrides可以帮助您修复依赖项依赖项上的漏洞。无需触摸package-lock.json文件。

{
  "overrides": {
    "foo": "1.0.0"
  }
}
Run Code Online (Sandbox Code Playgroud)

文档:https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides

注意:不要忘记检查您尝试覆盖的包是否有重大更改。


Lon*_*ely 5

package-lock.json手动编辑并将易受攻击的软件包版本更新为固定版本,然后使用

npm ci
Run Code Online (Sandbox Code Playgroud)

这将根据首先package-lock.json忽略来安装软件包package.json。然后使用

npm audit fix
Run Code Online (Sandbox Code Playgroud)

再次,以确保它是否正确完成。如果它没有帮助,那么使用其他给定的解决方案。

更多信息在这里:

https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

或在这里:https : //docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities

  • 这是一个很好的替代解决方案。如果这是在要发布的包内完成的,那么它将不起作用,因为 package-lock.json 文件不会发布,但对于本地使用包,这可能是“npm 审核修复”的最佳解决方案` 不是一个选项。 (2认同)