安全编码有章可循

　　使用编译器的安全检查和强化功能

　　不同的编译器是为不同的目的开发的。例如，C语言标准定义了许多未定义的、未明确规范的、由实现环境决定的行为。其它的许多问题都留给了“实施质量”，这意味着市场决定着行为是否合适。通常，开发团队可选择实施实现了安全特性的编译器，以此来改善安全性，也可以通过使用静态分析等方法来改善安全性。

　　在开始代码开发之前，开发者应当在最大程度上启用编译器的警告和错误。如果在日后再去应对所报告的问题，其代价将很昂贵。只要可能，要尽最大努力解决各种警告问题。如果解决警告问题并不现实，就要在代码中记录这些警告。

　　现代开发环境，如微软的Visual Studio包含着静态代码分析功能，而且能够自动应用。此集成开发环境不仅能够编译代码，而且还拥有200多个预定义的规则。开发人员可以根据这些规则，对照一系列潜在的漏洞来检查代码的诸多方面。

　　在编译和链接实际的二进制可执行文件时，应当禁用调试选项。例如，有些流行的商业级操作系统都曾被报告包含危急漏洞，可以使攻击者利用操作系统的标准的调试接口。该接口的设计目的是为了使开发人员在测试期间能够控制程序，在实际的生产系统中也保持可用。攻击者为了能够控制程序，会通过网络利用此接口，提升攻击者对调试器程序的特权。

　　有些编译时的验证工具可以利用类型限定符。这些限定符可以给程序加上注释，从而可以正式验证程序，免受已知漏洞的威胁。有些限定符不受语言的限定，并且可以检测那些本应当由开发者检查的“不安全的”系统调用，还有其它的工具可以检测特定语言的漏洞。

　　此外，还可以修改编译器，以检测对堆栈数据区域的恶意篡改。这种保护的一种简单形式就是“堆栈密探”。子程序的入口代码将“堆栈密探”放在堆栈上，并由编译器生成的子程序的退出代码对它进行验证。如果密探被篡改，退出代码就会终止程序，同时产生一个错误。

　　许多C/c++编译器可以检测不正确的格式字符串。例如，Gnu编译器Collection支持C的扩展。C扩展可用于标记包含不正确的格式字符串的函数，而微软的Visual C++ .NET中的/GS编译器开关可被用于标记运行时代码中的缓冲区溢出。

　　虽然类型和格式字符串的检查对于检测简单的错误非常有用，但对于检测更为复杂的漏洞，就显得有点儿小儿科了。有些编译时的工具会执行“污点分析”，即将输入数据标记为“污点”，确保在将此类数据用于易受攻击的功能之前，先对其进行验证。开源的“污点”分析工具Flayer就是一个好例子。此功能也被集成到了Perl语言中。其它的编译器也包括更广泛的逻辑，可以执行全面的程序验证，并根据正式规范来验证复杂的安全属性。程序验证编译器最常被用于检测C和C++程序和库中的漏洞和“有危险的”构造，其中也包括使程序易于遭受格式字符串攻击和缓冲区溢出的构造。

　　当然，还有其它的一些要求编译时支持的保护措施，这包括内存中的变量和代码位置的随机化，特别是被加载库的位置和汇编预处理程序位置的随机化，这可以减少C和C++程序遭受堆栈的缓冲区溢出的可能性。这常常要求编译器和运行时的支持。

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

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

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

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

　　编码期间和日后的检查

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

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

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

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

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

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

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

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

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

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

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

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

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

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