我们都知道黑客经常查找Web应用程序以发现其结构或者操作漏洞。比较常见的查找漏洞的一种方法，是将代码注入正在运行的程序，这个过程在SQL注入（SQL injections）和跨站脚本（cross-site scripting）中很常见。更复杂的注入方法是建立缓冲区溢出(buffer overflow)，强行让程序运行攻击者写的代码。

    基于注入的攻击已经证明十分有效，它们可能访问私人数据或者控制受感染的计算机。软件供应商不断地努力修复这些导致攻击成功的漏洞。但是如果程序在编译或者创建时黑客就可能注入恶意代码，又该怎么办呢？某些编制程序的方法使应用程序变得很容易受到一种叫做“cross-build注入”的攻击。

    利用编制过程

    现在的软件应用程序非常复杂，往往由许多不同的组件组成。为了加快应用程序的发展，开发人员都是结合已经写好的源代码和第三方组件来编制大多数软件。毕竟，既然可以很快找到程序部件，并能集成到应用程序中，尤其是许多组件又是开放源代码，可以通过GNU（通用公共授权）免费获得，为什么还要花几星期的时间重新开发程序部件呢？

    为进一步加速开发过程，简化项目管理，以及减少软件编制时间，现代的编译程序允许开发人员在项目设置中引用依赖关系信息(dependency information)。依赖关系信息可以从适用的代码库里检索预定组件，从而自动编制应用程序。例如，Maven是一种非常流行且广泛使用的编制系统，能够处理依赖关系管理和多项目关系。Maven和Ant、Ivy等相似的小工具能帮助开发人员处理大量的代码。这类管理会导致cross-build injection问题。

    如果开发人员在编制过程中自动检索开放源码组件等外部依赖文件，那么攻击者就有机会通过感染第三方组件将代码嵌入目标程序。完成这个过程有两种方法。

    第一，攻击者能感染装有组件的服务器，并以恶意的复制文件替代组件。第二，恶意软件编制人员能感染计算机的DNS服务器，将需求转给由攻击者控制的计算机。两种方法都很有效，因为开发人员及其采用的工具不会怀疑他们所使用的代码源及代码的完整性。大多数互联网用户都知道不能打开来路不明的邮件附件，然而软件开发人员经常会下载一些代码，集成到自己的应用程序中，而不会审核代码究竟对程序产生了什么影响。如果设置编制过程自动从互联网检索代码，这种方法的危险也就扩大了。

    风险加大

    用这种方法编制应用程序的完整性取决于提供开放源码组件的网站是否安全。应用程序还依赖用于找寻程序的网络基础设施。避免cross-build注入攻击最安全的方法就是不要采用合并依赖关系解决方案的自动工具。如果这种方法不可行，那么开发团队就必须创建内部代码库，制定需要严格执行的策略，以控制新代码或新组件加入代码库的过程。这些规则应包括为保证代码安全且合适所进行的复审。为减轻DNS受到的攻击，提供代码库的服务器应该只提供IP地址。

    如果cross-build 注入攻击变得十分广泛，它们就会逐渐破坏开放源码运动，而开放源码软件越来越得到认可的现象也会受到影响。如果程序在编制的时候就受到感染，那产生的恶意行为将会毫无限制。从长远来看，我认为数字签名代码和能检验签名的编制工具将会有更广泛的用途，它们能保证代码来自已知的出处，而且没有经过任何方式的篡改。