避免本地和非本地代码、被动代码和动态代码之间的安全冲突

　　应用程序常常依赖于用另一种编程语言编写的代码，或者在应用程序初期开发完成之后，还要使用另外一种编程语言进行后期处理。例如，有些非本地的JAVA应用程序可能会依赖本地的C代码来处理与硬件的接口。这是一个潜在的漏洞，因为即使JAVA代码部分并不易于遭受攻击，攻击者也有可能会对本地代码执行缓冲区的溢出攻击。

　　再举另一个例子，AJAX应用程序为了执行某项操作，有可能支持Web浏览器动态生成的JavaScript。因而，动态生成的代码有可能在原始的应用程序开发完成之后，再开发动态生成的代码。此时，如果动态生成的代码做出了关于应用程序环境和状态的不同假设，这就会导致AJAX应用程序的非法输入验证。

　　在这两种情形中，应用程序将本地代码和动态代码当作是潜在的不可信的实体，这一点是很关键的。另外，开发人员对发送给不可信代码、来自不可信代码的数据进行验证也是至关重要的。

　　编码期间和日后的检查

　　安全代码检查的主要目的是发现安全缺陷并确认可能的修复手段。测试报告应当提供关于软件可能的漏洞点的足够详细信息，使其开发者能够根据这些漏洞被黑客利用的可能性进行分类，并区分其优先顺序。应用指南应当包含在检查代码时应当考虑的问题清单。这会确保被检查的代码符合确定的标准，而不会受到检查者偏好的影响。

　　代码的安全检查的一些技巧：

　　何时检查：应当在软件的单元或模块水平上就进行代码的安全检查。在将软件的不同单元或模块提交进行编译和链接之前，程序员还应当检查软件单元或模块之间的接口缺陷。应当尽早并经常地在软件的生命周期进行源代码的分析和白盒测试。最有效的白盒测试是在个别模块或在功能性的进程单元水平上进行的，这种测试可以在将模块添加到更大的代码库之前相对轻松、快速地纠正发现的问题。全面的系统代码检查应当着重于不同组件之间的关系和接口上。

　　同行检查：程序员应当乐于请其它程序员检查自己的代码，因为程序员容易遗漏自己所犯的错误。

　　工具的使用：可以用静态、动态、二进制分析工具来发现常见的漏洞。例如微软就提供了FxCop的免费下载，这是一个静态的分析工具。此外，还有BinScope Binary Analyzer、Mini-Fuzz File Fuzzer 。不过，这些工具可以产生大量的似是而非的信息，因而应当结合人工检查使用，切不可用它完全替代人工检查。

　　代码检查者的能力：只有检查者洞悉安全问题时，人工检查才会有用。至少代码检查者应当清楚软件编码所用语言的漏洞及解决漏洞的方法，还要熟悉数据库、Web应用程序、加密技术等。

　　充分利用测试案例：程序员应当创建一些一般的测试案例。测试应当有助于指出明显的程序漏洞，它还应当是一个测试误用情况的机会。

　　威胁模型的检查：安全代码的检查应当包括检查威胁模型的文档，确保所识别的威胁在发布代码前能够被正确地处理。

　　遵循标准：安全的编码检查应当确保遵循所有的编码标准，其中包括使用安全的函数库，并排除被废止的函数。

　　此外，在安全的编码检查期间应当关注如下问题：

　　1、所有的组件都应当遵循同样的框架和确定的编码风格。

　　2、查找开发者在代码中的后门、调试命令、硬编码凭证、敏感评论、过于详细的错误消息等。这些增加到源代码中的要素可以使开发人员在测试时更易于调整软件的状态。在软件被编译并部署之后，这些元素也容易被利用。开发者应当从一开始就避免使用这些元素，除非绝对必要。

　　3、在软件系统的执行期间，要查找任何没有用到的调用和没有完成任何功能的代码。因为这些代码有可能包括会激发环境级别或中间件级别的进程调用，而系统并不要求在目标环境中出现这些进程。

　　4、还要查找恶意代码的线索和指示。例如，如果该代码是用C语言编码的，那么，检查者就有可能寻找可以指明漏洞特性的注释或复杂的、难以跟踪的代码部分，或者查找包含嵌入的汇编语言代码的源代码。检查人员应当检查所有已发现的漏洞，看其是否存在潜在的被利用的机会。可能被利用的漏洞称为安全漏洞，应当在代码发布之前就解决这些漏洞。