使用Maven有多安全？

Question

有人设置maven存储库和/或ip流的伪装以提供原始的伪装库副本但注入恶意或有害代码的风险和可能性或场景是什么.

防止此类风险和可能性的步骤和做法是什么？

Answer 1

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

对于客户端,它看起来是一个合法的工件:二进制JAR和SHA1匹配,即使它们检查备用镜像也是一样的.

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

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

如果你真的,真的想要保证你不会信任二进制文件 - 相反,你会下载所有源代码并在自己编译之前手工审查它们- 但这假设你有足够的合格资源和时间来执行首先回顾并信任您的整个构建工具链.

好吧,他们总是说层层安全.

Answer 2

我可以想到几个场景,虽然第一个不是Maven特有的.

1. DNS缓存中毒

   用于访问标准存储库的DNS数据可能会中毒,从而导致Maven从其他存储库下载工件.请参阅有关DNS缓存中毒的维基百科文章.

2. 非标准存储库

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

3. 存储库中毒

   基于Maven 将工件上载到中央存储库的指南,看起来中央Maven存储库从批准的存储库主机发布工件,因此工件的安全性取决于主机.我不知道有关成为一个批准的存储库主机的过程的细节,但由于很少列出它可能是繁重的.

   此外,中央仓库需要PGP签名用于所有部署,因此除非恶意用户获得对项目私钥的访问权限,否则我认为这是不可能的.

4. 传输过程中的神器修改(中间人)

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

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