使用 Maven 的安全性如何？

我认为一个专门的、足智多谋的攻击者可以执行MITM攻击，拦截对公共Maven存储库的所有请求，小心翼翼地将恶意字节码注入JAR工件，然后重新计算并提供SHA1哈希。

对于客户端，它将显示为合法的工件：二进制 JAR 和 SHA1 匹配，即使它们检查备用镜像也是如此。

我想唯一真正的解决方案是请求中央存储库支持HTTPS（并相信TLS本身没有被破坏）。

或者，一种实用的方法可能是设置一个通过HTTPS提供给内部客户端的Maven代理（Artifactory或Nexus）。这减少了攻击面，意味着您只需要保护从该服务器到外部世界的通信线路。我会使用完全独立的可信网络定期仔细检查代理上的 JAR 和哈希值是否与公共镜像上的 JAR 和哈希值匹配。

如果你真的，真的想要安全，你不会信任二进制文件——相反，你会下载所有的源代码，然后自己编译它们——但这假设你有足够的合格资源和时间来进行审查，并信任你的整个构建工具链。

好吧，正如他们总是说的那样，层的安全性。

我可以想到几种场景，尽管第一种不是特定于Maven的。

1. DNS 缓存中毒

   您用于访问标准存储库的 DNS 数据可能已中毒，从而导致 Maven 从其他存储库下载项目。请参阅有关DNS缓存中毒的维基百科文章。

2. 非标准存储库

   添加到 Maven 配置中的任何存储库都可能提供包含恶意代码的项目。通过仅使用您信任的第三方存储库来防止这种情况。

3. 存储库中毒

   根据 Maven 的将工件上传到中央存储库的指南，看起来中央 Maven 存储库从已批准的存储库主机发布工件，因此工件的安全性取决于主机。我不知道成为批准的存储库主机的过程的具体信息，但是列出的内容很少，这可能很繁重。

   此外，中央存储库要求所有部署都使用PGP签名，因此除非恶意用户获得对项目私钥的访问权限，否则我认为这是不可能的。

4. 传输过程中的伪影修改（中间人）

   Maven 对所有工件执行自动校验和验证，因此攻击者必须修改工件和随附的校验和以注入恶意代码。我不知道你是否可以完全阻止它，但为了确保你注意校验和，确保你的校验和策略没有设置为忽略。请参阅设置文档。

正如其他评论者所提到的，防止恶意代码进入生产部署的一个好方法是仅使用内部 Maven 存储库进行生产发布版本。通过限制对向该存储库添加依赖项的访问，您可以确保在您选择的任何级别上都对其进行了验证，例如校验和双重检查，源扫描。