Dependency Confusion
Last updated
Last updated
学习和实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习和实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
总之，依赖混淆漏洞发生在项目使用一个 拼写错误、不存在或 未指定版本 的库时，而所使用的依赖库仓库允许从 公共 仓库 获取更新版本。
拼写错误：导入 reqests 而不是 requests
不存在：导入 company-logging，一个 不再存在 的内部库
未指定版本：导入一个 内部 存在的 company-requests 库，但仓库检查 公共仓库 以查看是否有 更高版本。
在所有情况下，攻击者只需发布一个 恶意包，名称与 受害公司使用的库相同。
如果您的公司试图 导入一个不是内部的库，那么库的仓库很可能会在 公共仓库 中搜索它。如果攻击者创建了它，您的代码和运行的机器很可能会被攻陷。
开发者 不指定任何版本 的库，或仅指定一个 主要版本 是非常常见的。然后，解释器将尝试下载符合这些要求的 最新版本。
如果库是一个 已知的外部库（如 Python 的 requests），攻击者 无法做太多，因为他无法创建一个名为 requests 的库（除非他是原作者）。
然而，如果库是 内部的，如本例中的 requests-company，如果 库仓库 允许 检查新版本也在外部，它将搜索一个公开可用的更新版本。
因此，如果一个 攻击者知道 公司正在使用 requests-company 库 版本 1.0.1（允许小版本更新）。他可以 发布 库 requests-company 版本 1.0.2，而公司将 使用该库而不是内部库。
此漏洞在 AWS CodeArtifact 中被发现（阅读 此博客文章中的详细信息）。 AWS 通过允许指定库是内部还是外部来修复此问题，以避免从外部仓库下载内部依赖。
在 关于依赖混淆的原始文章 中，作者搜索了数千个暴露的 package.json 文件，包含 JavaScript 项目的依赖。
学习和实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习和实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
