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

来源：msdn 作者： 出处：综艺读书 2006-11-09 

关 键 词：协议  文件格式  数据结构  设计  加密  

下一页 1 2 

　　我非常荣幸在过去的几年中曾经与数千位出色的开发人员一起工作，他们希望了解如何编写更安全的软件。在此期间，我也从构建安全系统方面表现出色的人员那里学到了很多东西，这使我开始思考一个问题。我在想“安全开发人员”之间是否有共同的技能或习惯。答案是当然有!本文介绍了安全代码开发人员之间共有的一系列习惯。

　　目前我可以肯定的一点是，任何看过这篇文章的人都会立即发现自己不具备的习惯。这非常好。我知道除此以外还有其他好的想法。这里只是列出我所观察到的!因此，下面介绍的是我在这几年中注意到的几种典型习惯。

　　习惯 1:承担责任

　　这是长期以来“没有银弹”观点的一种转变，该观点是 25 年前 Fred Brookes 在其“人月神话”一书中提出的。能否使您的产品具有足够的安全性完全取决于您自己。其他任何人或任何出色的工具或编程语言都无法解决所有安全隐患。不要误解我的意思，我喜欢源代码分析工具，但他们无法神奇般地修复您的所有安全漏洞。只有您自己可以做到这一点。

　　只有创建安全设计和编写安全代码的开发人员才能构建出安全产品。最后，编写代码由个人完成。工具不能取代个人完成这项工作。因此，您产品的安全性就是您的责任!Blaster 和 CodeRed 蠕虫利用的就是个人编写的代码(参见图 1)。

　　

　　图 1 有弱点的代号是人编写的请记住，要仔细检查所有代码，所有代码都有可能受到攻击。没关系。受到攻击也没关系。关键是，您的代码是否会遭到破坏?只有您可以决定最终结果。因此您的代码必须要使您自己满意。您必须对代码的质量充满信心，因而在晚上可以安心地休息，因为您知道如果受到攻击，您已经做好了万全的准备，可以防止代码受到破坏。

　　如果有可能，最好请一位安全专家对您的代码进行专业评审。不要让那些对安全一无所知的人来检查您的代码，不要期望他们能够找出安全错误和漏洞。要留出充分的时间让真正了解安全性的人检查您的代码。

　　不要过于自负，在需要帮助时应主动寻求帮助。我刚刚提到了，您不应完全依赖于工具，但您应该利用一切可利用的资源。请对您的代码运行所有可用的源代码分析工具，并经常这样做。利用所有可用的防御性语言构造和库技巧。例如在 C# 语言中，将执行数组访问的面向网络的代码打包，其中数组索引来自网络请求，采用 checked 操作符的形式，以检测可能出现的整数算法错误。

　　习惯 2:永远不相信数据

　　对于这一点，我已经说过无数次，但我还要重申一遍:所有输入在得到证明之前都是不可信的。看看那些最让人深恶痛绝的安全漏洞，您就会发现它们所拥有的最显著的共性就是开发人员相信了输入的数据。问题在于您的代码假定这些数据是可靠的，那么如果您的假设不正确将会怎样?在某一天您的应用程序很可能会崩溃。如果严重的话，攻击者可能会在您的流程中插入恶意代码并破坏您的流程。

　　安全系统的定义是只执行所要求的任务而不执行其他任务的系统。这一定义有些古怪。当输入的数据存在信任问题时，您往往会让系统执行其他任务。常见漏洞和披露 (CVE) 数据 (cve.mitre.org) 的粗略分析显示，从 2001 年至 2004 年，CVE 跟踪的所有安全漏洞中有 47% 的漏洞属于输入信任问题。最显著的问题就是缓冲区溢出、整数算法错误、跨站点脚本和 SQL 插入错误。我们开始不断看到这种漏洞的新变体，如 XPath 插入漏洞和轻型目录访问协议 (LDAP) 插入漏洞。

　　您可以根据几个简单规则纠正输入信任问题。首先，不要只看您知道的错误，这就假定了您知道所有错误，并可预测将来发生的所有错误。查找错误是可以的，但条件是这不是您唯一的防御手段。更好的策略是将输入控制在您知道的正确的范围内。对于诸如 C# 和 Perl 此类的高级语言，我喜欢使用正则表达式来确保这一点。

　　其次，抛弃您已知的错误。例如，如果某人通过您的代码远程请求一个文件，并且文件名中包含不确定的字符(如:or \)，请拒绝该请求。并且不要告诉攻击者原因;只要说“找不到文件”即可。

　　最后，净化数据，这一点并非对所有情形都适用。例如，在 Web 服务器中，您应对可能不受信任的输入的输出进行 HTML 编码。

　　习惯 3:模拟针对您的代码的威胁

　　您应该有威胁模型对吧?利用威胁模型，您可以了解您的软件可能面临的风险，并确保您有适当的降低风险的举措。但威胁建模带来的益处不仅仅限于安全设计。威胁模型还可以帮助您确保代码质量。威胁模型可以告诉您数据的来源。数据是远程的还是本地的?数据来自匿名的用户，还是来自可信赖的(已验证的)用户、管理员?

　　通过掌握这些信息，您可以确定您的防御措施是否到位。例如，匿名用户和远程用户都可以访问的代码最好是非常安全的代码。这并不是说只有本地管理员可以访问的代码就应该是不安全的代码，我的意思是远程可访问的代码(尤其是默认情况下运行的代码)必须非常安全，这就意味着要提供更多的防御措施、对代码进行更详细的审查、更注意代码的细节。此外，威胁模型还可以告诉您受保护的数据的特点。例如高价值业务数据和个人可识别的信息应受到严格保护。您的防御措施是否到位?

　　确保您的威胁模型准确并保持最新，然后确定您的代码的所有入口点，并按可访问性(远程还是本地，高权限还是低权限(或无权限)用户)对其进行排序。首先要对最多人可访问的代码进行最深入的审查。最后沿着匿名数据路径审查所有代码，换句话说，从每个匿名可访问的入口点开始，沿着该路径跟踪数据，检查代码的准确性。

　　习惯 4:始终提前一步

　　安全环境总是在不断变化中。似乎每个星期都会出现安全问题的新变体。这就意味着您必须不断演变并了解新威胁和防御措施，否则您就要承受由此带来的后果。

　　可保持领先的几个简单策略是经常阅读关于软件安全性的优秀书籍。同时从您过去的错误中吸取教训，当然能够从他人的错误中吸取教训则更好。要做到这一点，您可以阅读 bugtraq — 转至 securityfocus.com 并同意通过您的收件箱接收 bugtraq 发布的内容。但请务必采纳以下建议:创建一项收件箱规则，将发布的内容转移到一个特定的文件夹中，以便您进行处理。这一点非常重要。 更多内容请看FreeBSD系统安全管理  Linux服务器的安全性能  MySQL安全专题，或进入讨论组讨论。

下一页 1 2 

【收藏此文】【大 中 小】【打印】【关闭】

较早的文章：程序员的灯下黑：不要忘记你的目标

较新的文章：高效开发与彻底测试