8个开发更安全代码的简单规则

来源：msdn 作者：出处：巧巧读书 2006-11-09 进入讨论组

习惯 5:模糊!

　　模糊化处理是一项测试技术，旨在找出可靠性错误。经证实，有 1% 的可靠性错误为安全漏洞，很有可能被利用!当然，缓冲区溢出可能会使应用程序崩溃，但假定出现设计完善的恶意负载，可能不会出现应用程序崩溃，攻击者可能会按照他的意愿运行代码。

在这一点上我们的格言是“今天拒绝服务就是明天代码的执行”。

　　偶然的运气或模糊化处理几乎可以找出所有文件解析错误/漏洞。Microsoft 对 XLS、PPT、DOC 和 BMP 等多种文件格式进行了解析，并发现了多个安全漏洞。大多数供应商都存在类似的漏洞，因为对复杂的数据结构进行解析是一项非常复杂的任务，复杂的代码会存在错误，其中一些错误会暴露出安全漏洞。

　　您必须对解析文件和网络流量的所有代码进行模糊处理。Microsoft 的安全开发生命周期 (SDL) 中就此对文件格式有何意义有非常具体的介绍。您必须利用一个文件模糊处理程序，通过对不正确文件的 100,000 次迭代对所有解析器进行模糊处理。目前有一些比较好的模糊处理程序，在我和 Steve Lipner 合著的“安全开发生命周期”一书 (microsoft.com/MSPress/books/8753.asp) 中，我们提供了一个文件模糊处理程序及 C++ 源代码。

　　关于模糊化处理还需要注意一点。如果出现了崩溃，不要认为这只是崩溃。这些所谓的崩溃中有很大一部分都是在请求某人编写漏洞。因此不要简单地将一次崩溃认定为“只是一次崩溃”。

　　习惯 6:不要编写不安全的代码

　　在 Microsoft，我们使用质量把关的概念来帮助降低开发人员使存在漏洞的代码流入产品的可能性。质量把关是在代码上运行一组源代码分析工具，然后进行登记，对所有问题进行标记。所有发现的问题必须在登记完成前修复。您还可以执行严格的代码规则，如阻止对禁用功能的使用，如不能调用 strcpy 或 strncat，不允许无用的加密。(Microsoft 已经禁用了超过 100 个针对新代码的 C runtime 函数!)例如，就加密算法而言，我们不允许在新代码中使用 DES(密钥长度太短)、MD4 或 MD5(它们目前都已被破解)，除非行业标准中规定使用这些算法。

　　不要重新发明功能。如果您具备对特定文件格式进行解析的代码，那么您无需两套或三套解析代码;只需一套解析代码即可，使其功能足够强大并将其捆绑在一个可在多个项目之间使用的窗体中。

　　最后，请记住，工具不能取代人来了解如何编写安全代码。这就是安全和隐私教育为何如此重要的原因。您需要全面深入的了解这些概念，对您的工具无法进行的调用和洞察做出判断。

　　习惯 7:识别策略不对称

　　这是我最喜欢的一种习惯。记住，作为一名软件开发人员，安全方面的隐患会对您不利。我喜欢称之为“攻击者的优势和防御者的尴尬”您需要确保代码和设计在 100% 的时间内 100% 准确，这是不可能的。更糟糕的是，您还必须在固定的预算内达到这一无法实现的目标，同时还必须考虑到可支持性、兼容性、可访问性和其他“能力”的要求。攻击者会用足够长的时间来找出错误，然后向全世界宣布您的应用程序是不安全的。

　　在习惯 6 中，我曾经提到，您应该停止编写新的不安全代码。对于习惯 7，您应该关注所有代码，因为攻击者会攻击所有代码，无论是哪个时期的代码。花些时间查看旧代码，找出安全漏洞，并认真考虑受到贬低的旧的不安全功能。如果您使用的是灵活的开发方法，那么您应该考虑派一名或多名专业人员修复旧代码，使其质量与新代码持平。

　　习惯 8:尽可能使用最佳工具

　　最后，尽可能使用最佳工具。我喜欢源代码分析工具，并且喜欢所有能够帮助我编写出更安全代码的技术。正如我提到的，工具并非万能的，但它们会有所帮助。会有很大帮助!工具还可以帮助衡量源代码分析得出的问题。工具可以快速扫描大量代码，比人工速度要快得多。而且，这还可以使您感觉到某些代码有多么“差”。

　　我喜欢的一种技巧就是使用可能的最高警告级别编译代码，例如在使用 Visual C++? 时使用 /W4 警告级别，或者在使用 gcc 时使用 –Wall 警告级别。如果您在代码中发现了大量警告，那么可能该代码还存在编译程序或其他工具没有发现的其他错误。对于这种代码，在提供代码前应该对其进行更详细的安全检查(参见习惯 3)。

　　我发现我所尊敬的 Microsoft 内部和外部的开发人员具备了这八种良好的习惯。这些习惯本身不会使您成为一流的安全开发人员，但它们肯定会对您有所帮助!文字：http://www.qqread.com/itlife/e276681.html