在做好安全软件开发的准备之后，开发团队还需要清楚安全编码的原则。这是开发任何健壮、安全软件的重要基础。

    保持代码的简洁

    代码库越小越简单，就越容易验证软件的安全性。有些代码的功能强大，可能会造成严重的后果，通过减少实现这些功能的源代码模块的大小，就可以极大地减少代码中的漏洞数量。

    在此，列示几个缩短和简化代码的方法：

    1、确保软件仅包含所要求或规定的功能。增加不必要的功能会增加软件的攻击面，并增加软件被破解的可能性。

    2、尽可能地将大的或复杂的功能分解为更小、更简单的功能。这会使系统更易于理解和记录，在验证个别组件、整个系统的安全性和正确性时也更为轻松。

    3、在构建系统时尽量使其依赖关系尽可能地少。这样做有一好处，即能够确保在不影响整个系统操作的前提下就可以禁用或替换任何过程模块或组件。

    4、对软件进行封装，限制泄露敏感信息，限制外部所造成的影响。

    软件开发团队还应当考虑软件的大小和简易性之间的平衡关系。如果将功能分解成太多的小功能，在查看不同的功能如何协同工作时，就会存在困难。

    确保可以向前和向后追溯源代码

    开发团队应当使软件易于跟踪每个要求，跟踪其设计形式，以便于追溯其源代码。当然，开发团队还要使软件能够根据代码的形式，追查其实现的每一个需求。[page]
    代码的可重用性和可维护性

    使代码安全（简易、可理解、可跟踪）的一些特性也有助于代码的可重用性和可维护性。如果代码很容易被重用，其安全性就可以传递给未来的软件项目。如果代码易于维护，在维护过程中就不太可能增加漏洞。

    开发团队应当尽力构建可以预测未来事件的代码。要确保软件需要的所有值源自数据库或外部的属性文件，而不是源自硬编码（硬编码是指在计算机程序中将变量用一个固定值来代替）。例如，在JAVA中，可考虑在方法签名中使用输入对象的bean可重用组件，而不是指定数据类型和预期值。这会使程序的功能按照需要而变化，并实现代码重用。

    遵循安全编码的标准和指南

    某些特定语言已经有了明确的安全编码的实践和模式，开发团队应当优先选择并采用其安全编码的标准和指南。否则，团队将不能避免在软件开发中出现常见的编码漏洞和潜在的易受攻击的软件架构。开发团队应当积极地选择应对这些缺陷的安全方法。这些标准和指南既涉及到编码过程的错误做法和正确做法。例如，美国的卡内基梅隆软件工程学院就发布了C、C++、JAVA等语言的着名安全编码标准。

    还有一个大名鼎鼎的标准，即汽车工业软件可靠性联会（MISRA）标准，它虽然不是专为解决软件安全而制定的标准，但它确实可以作为编码指南的一个例子。该机构是相关行业汽车制造商和公司的协会，其用户早已经超出了汽车行业。它为C和C++语言创建了安全编码指南，并为嵌入式电子系统提供了有关可靠性的最佳实践。改善代码的质量是改善代码安全性的一个重要部分。

    在确定好标准之后，开发团队应当对软件执行一致性测试，判定编码是否正确地遵循了选定的编码标准。CERT的源代码分析试验室（SCAL）提供了针对CERT的C语言安全编码标准的系统一致性测试。成功通过一致性测试的软件就可以得到CERT加盖的一致性测试印章。

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

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

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

    现代开发环境，如微软的Visual Studio包含着静态代码分析功能，而且能够自动应用。此集成开发环境不仅能够编译代码，而且还拥有200多个预定义的规则。开发人员可以根据这些规则，对照一系列潜在的漏洞来检查代码的诸多方面。[page]
    在编译和链接实际的二进制可执行文件时，应当禁用调试选项。例如，有些流行的商业级操作系统都曾被报告包含危急漏洞，可以使攻击者利用操作系统的标准的调试接口。该接口的设计目的是为了使开发人员在测试期间能够控制程序，在实际的生产系统中也保持可用。攻击者为了能够控制程序，会通过网络利用此接口，提升攻击者对调试器程序的特权。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。