这个故事始于 Docusaurus（基于 React 的开源文档项目）的维护者 Sébastien Lorber 注意到对包清单的 Pull 请求更改。以下是对流行的 cliui npm 包提出的更改：

具体来说，让我们注意使用不熟悉的语法的 npm 依赖项更改：

  "dependencies": {
    "string-width": "^5.1.2",
    "string-width-cjs": "npm:string-width@^4.2.0",
    "strip-ansi": "^7.0.1",
    "strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
    "wrap-ansi": "^8.1.0",
    "wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"

大多数开发人员希望在包或 Git 或基于文件的 URL 的值中看到 semver 版本范围。然而，在这种情况下，有一个特殊的 npm: 前缀语法。这是什么意思？

什么是 npm 包别名？

npm 包管理器支持包别名功能，允许为包定义自定义解析规则。因此，无论通过代码或锁定文件引用包，它将解析为别名指定的名称和版本。

因此，在此拉取请求中提出的更改的情况下，包 string-width-cjs 将解析为版本 ^4.2.0 中的包 string-width。这意味着将有一个 string-width-cjs 的 node_modules 目录条目，但包含 string-width@^4.2.0 的内容以及锁定文件 (package-lock.json) 中的类似行为。

包别名是 npm 包管理器的一项功能，可用于支持 ESM 与 CJS 等情况。

话虽如此，包别名可能会被滥用。在一篇可追溯到 2021 年的文章和安全披露中，Snyk 大使 Nishant Jain 演示了如何欺骗官方 npmjs 注册表，根据包别名错误地提供依赖信息，作为依赖混淆和供应链安全问题的一部分。

拉取请求是良性的，不存在供应链攻击的风险。 然而，Sébastien 对包名称的担忧导致发现了潜在的安全风险。

在 npm 锁定文件中查找有关恶意模块的可疑行为

为了检查拉取请求，Sébastien 使用了 lockfile-lint。该工具会检查 package-lock.json 或yarn.lock 等锁定文件是否有篡改迹象，确保未注入恶意包而不是原始 npm 包。

运行该工具显示以下警告：

npx lockfile-lint --path package-lock.json --allowed-hosts yarn npm --validate-https --validate-package-names

detected resolved URL for package with a different name: string-width-cjs
    expected: string-width-cjs
    actual: string-width

detected resolved URL for package with a different name: strip-ansi-cjs
    expected: strip-ansi-cjs
    actual: strip-ansi

detected resolved URL for package with a different name: wrap-ansi-cjs
    expected: wrap-ansi-cjs
    actual: wrap-ansi

 ✖ Error: security issues detected!

免责声明：lockfile-lint 是我在 2019 年开发的一个工具，该工具披露了锁文件的安全问题： 为什么 npm lockfiles 可能成为注入恶意模块的安全盲点.

高度警惕：npm 上的流行软件包看起来很相似

鉴于上述 lockfile-lint 结果，Sébastien 在 npm 上查找了这些包名称，并令人惊讶地发现它们确实存在于公共 npm 注册表中：

• https://www.npmjs.com/package/string-width-cjs
• https://www.npmjs.com/package/strip-ansi-cjs
• https://www.npmjs.com/package/wrap-ansi-cjs

Sébastien 观察到这些包名称不仅存在于 npm 上，而且还表现出可疑的特征。这些包没有绑定到公共源代码存储库，在检查时没有任何实际代码，并且是匿名发布的，没有任何相关的个人信息。

查看 npm 包 strip-ansi-cjs，没有 README 或源代码存储库。然而，有许多合法且流行的软件包引用了相同的行为。

事实上，这个特定的软件包很受欢迎，我们可以从它的 529 个依赖项（依赖于这个软件包的其他软件包）和每周 7,274 次下载中看出。

查看 strip-ansi-cjs 的代码，它显示该包中只有一个文件，即包清单 package.json 文件。

那么，为什么一个不做任何事情的软件包会获得如此多的下载，以及为什么还有这么多其他软件包依赖于它？

让我们检查一下这些 npm 包的作者。

这三个软件包均归himanshutester002 所有，它们的软件包均于去年发布，并带有程序化版本号。一些有趣的观察结果值得指出：

• isaacs-cliui npm 包可能是对 Isaac 自己的 cliui 项目分支及其命名空间下的合法 npm 包的误植尝试：@isaacs/cliui。
• azure-sdk-for-net npm 包可能是一种依赖混淆活动的尝试，以攻击同名的私有包。
• link-deep npm 包占用了与 lodash 等实用程序包相关的流行功能。

您还可以注意到，用户 himanshutester002 在 npmjs 上的此用户个人资料页面上没有可识别信息。

我们之前注意到 strip-ansi-cjs npm 软件包有超过 500 个其他软件包使用它，因此，这可能是流行度的积极指标。让我们看看它们：

这似乎是可信的，因为它被列入名单，但真的是这样吗？
例如，像 clazz-transformer 或 react-native-multiply 或 gh-monoproject-cli 这样的名称似乎合法，但它们是吗？

这里是react-native-multiply npm包页面：

该软件包几乎没有下载，其作者是一位匿名 npm 用户，没有任何可识别信息。该包重定向到的源 URL 存储库是不存在的 https://github[.]com/hasandader/react-native-multiply。 GitHub 用户个人资料看起来也非常可疑，缺乏实际活动。

虽然 npm 包似乎包含源代码，但仔细观察会发现它是为“hello world”应用程序原型生成的代码示例。

你还想知道，如果这个包只是一个乘法库，那么为什么它需要 776 个依赖项来执行以下操作：

import { multiply } from 'react-native-multiply';
const result = await multiply(3, 7);

虽然有一些笑话说 JavaScript 通过过度的依赖项使用而导致嵌套包的天文数字树，但具有 776 个直接依赖项的项目太大了。

在所有这些依赖项中，有我们的故事开始时的 3 个可疑的 npm 包：string-width-cjs、strip-ansi-cjs 和 wrap-ansi-cjs：

我们提到过 strip-ansi-cjs 依赖项之一名为 clazz-transformer。我们来看一下：

让我们解释一下这里发生了什么。 ​​npm 包 clazz-transformer 的 README 页面上的标题 class-transformer 被故意误命名。此外，其源代码存储库 https://github[.]com/typestack/class-transformer 与包名称不相关，这引发了对其合法性的担忧。

GitHub 上关联存储库的typstack/class-transformer 具有 package.json 文件，如下所示：

GitHub 上的 package.json 文件没有显示依赖项声明，但如果我们检查 npmjs 上实际包的源代码，我们会看到此 clazz-transformer 打包时使用的 437 个依赖项。再次，他们非常方便地捆绑了 3 个可疑的 *-cjs 软件包：

对可疑 npm 包发现的进一步思考

在我们得出进一步的结论之前，有必要提及我们在上面观察到的 npm 包的一些特征：

• React Native 包似乎源自 create-react-native-library 脚手架工具。该工具还具有默认的乘法函数示例，作为为新项目生成的库存源代码的一部分。
• 包具有可以从 Next.js 14 入门样板派生的目录和文件结构以及依赖项，例如使用 npx create-next-app@14 创建的包。

我们在 Sonatype 的同行之前已经发现过类似的软件包淹没开源注册表的案例。在这些情况下，最终目标是开发人员用 Tea 代币奖励自己，这是一个用于通过开源软件货币化的 Web3 平台。

在上述包中找到一些 tea.yaml 文件进一步支持了这一论点，即该活动的部分目的是通过滥用 Tea 来挖掘 Tea 代币。

今年早些时候，2024 年 4 月 14 日，一位茶论坛用户发表了一条评论，进一步支持了对茶滥用的担忧：

在给出结论之前，我要真诚地感谢 Sébastien Lorber 谨慎的维护者心态，并帮助揭示潜在的 npm 供应链攻击的线索。

string-width-cjs 发生了什么？

此时，我非常有信心我可以继续在其他依赖于 string-width-cjs 的软件包中找出漏洞，以找到非常可疑的真实合法性指标。

我的假设是，所有这些依赖包和下载量增加的唯一目的是为 3 个 *-cjs 包创建虚假合法性，以便在适当的时候，在适当的受害者参与的情况下，这些假包将安装，然后安装新的恶意版本。

为了帮助您在使用开源软件时保持安全，我强烈建议采用安全实践，特别是以下后续教育资源：

• 为什么 npm 锁定文件可能成为注入恶意模块的安全盲点
• 10 npm 安全最佳实践
• NPM 安全：防止供应链攻击

我们是否在他们的不法行为中发现了供应链安全活动，或者这一切都与金钱轨迹有关，因此可以归因于垃圾邮件和滥用 npm 和 GitHub 等公共注册中心来挖掘 Tea 代币？

无论如何，请保持警惕。