清单之惑：npm供应链面临的新威胁

作者 | Sergio De Simone

译者 | 平川

策划 | Tina

最近，npm 前工程经理 Darcy Clarke 在一份报告中指出，npm 注册没有根据相应 tarball 包的内容验证清单信息。Clarke 说，这会导致双重事实来源，攻击者可以利用它来隐藏脚本或依赖项。

Clarke 将这个漏洞命名为“清单之惑（manifest confusion）”。其根源在于，npm API 要求维护人员在提交包的 PUT 请求中以及在随 tarball 包上传的 package.json 文件中都要提供有效的清单。由于 npm 服务器不会验证这两个清单，所以即使它们不一样，也没有人会注意到。这对于 npm 客户端来说尤其严重，因为这会使人无法知道哪个才是“真实”的清单。Clarke 在他的文章中展示了如何使用 npm CLI 或直接访问 npm API 来重现这种不一致。

Clarke 说，这一点影响很大。例如，npm 上有个包可能会显示它没有依赖项，而实际上它有。同样，它显示的包名或版本可能与 package.json 中的不同，而这可能会导致缓存中毒。更糟糕的是，它可以隐藏它将在安装期间运行脚本的事实。

上面列出的所有不一致都是可以被利用的漏洞。例如，一个包可以将自己伪装成不同的包，诱使别人错误地安装它；让用户在不知情的情况下安装隐藏的依赖项，诸如此类。

Clarke 进一步指出，这个问题会影响到 npm 生态系统中的许多第三方客户端和工具，以及包管理器，所以你可能需要仔细检查一下你喜欢用的工具。

Clarke 最后建议，所有 npm 用户都不要再依赖 npm 的注册清单文件，而应该使用 package.json，不过 name 和 version 两个字段除外。

在接受 InfoQ 采访时，Sonatype 安全研究员 Ax Sharma 强调，这种不一致不一定是恶意的，可能是源于合法的克隆或分叉，或者是由于开发人员在更新包时没有清理过时的元数据。他还提出了一点小小的异议：

相信 package.json 并不一定比相信包的 npmjs 页面更好——两者都不是完全可靠的。

根据 Sharma 的说法，要解决这个问题需要借助安全工具进行更深入的分析，例如，对恶意文件或受到攻击的文件进行基于散列的分析，即高级二进制指纹。

另一个有用的建议来自 J. M. Rossy 的推特，他建议默认关闭脚本。

如果你对这个清单之惑感兴趣，请阅读 Clarke 的原文，其中有许多其他的见解。

原文链接：

https://www.infoq.com/news/2023/07/manifest-confusion-npm-bug/