安全编码指南是解决软件漏洞问题的关键？

开放式Web应用程序安全项目

最近，我对开放式Web应用程序安全项目(OWASP)这一组织有所了解。如果你不了解他们作为非盈利性机构管理情况的话，下面就是组织的使命宣言：

“开放式Web应用程序安全项目(OWASP)是一家开放性的组织，致力于提供涉及计算机和互联网应用程序等方面公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。我们认为应用程序安全属于人性、过程和技术方面的问题。提高应用程序安全性的最有效方法是所有领域的情况都获得改善。”

OWASP目前开展了多个项目，它们是：

保护项目：创立可以防止设计和部署过程中出现安全问题的工具。

监测项目：开发可以发现设计和部署过程中出现安全问题的工具。

生命周期项目：设计可以加入到软件开发生命周期中处理安全相关问题的工具。

安全代码开发项目

该项目引起我注意的是安全编码实践快速参考指南项目。该小组的目标是减少采用了最佳做法准则的软件中存在的漏洞。为此，他们刚刚发表了自己编写的快速参考指南：

“通用软件安全编码实践中应该采用技术无关性设置，采用全面的备忘录格式，并且应该可以集成到开发生命周期中。其关注重点是安全编码的需求，而不是弱点和漏洞。

它包含了对软件安全性原则进行的介绍和关键术语表。目的是作为一个安全编码启动工具和简易参考，可以帮助开发团队快速了解安全编码实践。”

该项目的一名成员基思·特平制作了参考指南的视频概述版本，并且对OWASP选择开发该项目的目的进行了说明。

几个问题

由于软件开发领域不是我的专长。我决定邀请记者编程和开发栏目的贾斯廷·詹姆斯进行介绍。为了让广大读者对该问题有更深入的认识，贾斯廷就OWASP正在进行的工作发表了自己的意见。下面就是他的观点。

记者：作为一名软件开发人员，在编写软件的时间你会给出什么样的安全建议?

贾斯廷·詹姆斯：说实话，对于安全实践这一问题，我也没有什么一定之规。我关注的重点是错误密度率。在我看来，这是优秀的软件开发人员与差劲的程序员之间的关键区别。在其它条件相同的情况下，差劲的程序员就意味着出现的错误数量更多。而且，这会导致更多可用漏洞的出现。

为了确保安全，软件开发人员应该重视以下几方面的问题：

保证逻辑清晰代码简洁：如果开发团队里技术最差的人员不能理解的话，就说明代码太复杂了。代码是否能被理解对于错误的发现、跟踪和修正来说是至关重要的。

不要使用C/C++：尽管，关于微软补丁日的问题，我在很多年前就已经说过。但看到相关的安全问题还是屡屡出现。一次又一次，根本原因还是那个缓冲区溢出问题。对于所有的第一级和第二级语言(从使用方面来分类的)来说，只有在C/C++中，可以编写导致这种情况发生的代码!

站在巨人的肩榜上(选择专家编写的代码)：如同专家们一样，我喜欢编写加密算法，并利用验证库，组件，系统等等;不论它们采用的是开放还是封闭源代码模式。对于供应商的选择，我也非常慎重。

记者：你是如何看待其他人编写的软件呢?基于这一点，对于软件开发公司选择的安全实践，你有什么看法?

贾斯廷·詹姆斯：大部分安全实践在降低风险和损害方面获得的成绩都会被差劲的软件开发人员所抵消。说实话，行业内充满了伪装、欺骗和假冒行为，将绝望的人员清理出去，并保持希望的话，情况就会有所改善。

我一直在负责招聘工作，当出现关键项目需要人力补充情况的时间，要做的事情不是花费九个月的时间寻找一名顶级程序员。我在这里说的也不是“摇滚明星”。我的意思是普通的传统模式的优秀程序员。他们非常罕见。

我在前面的答案已经解决了这一问题，这就是：在要求明确的情况下，他们是否能够编写出高效、清晰、简洁的代码。如果该规范是模糊的，他们能胜任填补空白的要求?

请注意，在代码开发安全实践中没有任何错误。但问题的关键是，它们不是必须的，作为一个行业，我们应该通过帮助不太合格的软件开发人员提高编写优秀代码的能力的方式来获得合格的程序员。现在，软件开发的难度还是就象天书一样，并且我们不知道原因在哪里。

记者：对于OWASP和其在软件行业中的作用，你持什么观点?

贾斯廷·詹姆斯：我对他们不是很了解。但从网站和.NET项目的情况来看，信息已经很过时了。我发现有四分之一的文章是五年以前写的，这都属于上一个生命周期了。

记者：在读过参考指南后，你有什么看法?它是否涉及到所有的正确项目?

贾斯廷·詹姆斯：总的来说，里面包含了我希望软件开发人员关注的几乎所有常见准则。不过，列表中也存在一些“安全剧场”(意指在没有明显改善安全措施的情况下让用户感到安全的方法)类型的项目。举例来说，如果用户名不可行的话，为什么说“无效的用户名/密码”将帮助掩盖实际用户名的存在情况，而“忘记密码”就会帮助攻击者。

在大多数情况下，这都属于一份优秀的指南。为了部署所有这些步骤需要开发大量代码。幸运的是，在大多数流行框架环境下进行工作可以达到同样的目的。

记者：安全编码实践参考指南提到，开发团队的具体成员应该：

“具备责任心，经过适当的培训，拥有相应的工具和资源，可以对整个系统的设计和实施进行确认，以确保安全性。”

这种模式目前被采用了么?拥有具备相关技能的人员有多重要?

贾斯廷·詹姆斯：确实，在资金不受到限制，时间充裕的情况下，建立一个专门的团队是可行的。但对于大部分开发人员来说，这是不可能实现的。遵循指南将增加资金和日程方面的压力。

此外，软件也变得越来越庞大复杂，个人很难把握代码的全部内容。因此，如何让所有具体成员发挥作用?个人认为一种可行的办法就是让大家都参与到安全开发实践的使用中。

记者：软件开发公司是否有足够的兴趣或者动机在参考手册中使用检查表?

贾斯廷·詹姆斯：在这里，关键的问题是“足够”。大部分公司在安全方面出现问题是因为动机“不足”。OWASP给出的列表非常好，但是里面并没有我们以前没见过的内容。实际上，在高中的时间，我就见到过包含非网络具体内容的类似材料。

记者：最后，我想问一下将检查表集成进开发过程是不是正确答案。如果不是的话，你认为需要的是什么?

贾斯廷·詹姆斯：我认为检查表属于短期答案的组成部分。但是，所有人都会有自己的想法。确定OWASP的的安全编码实践怎样才能与自身框架集成需要进行选择，必需的调整以及标注出所需的代码，这些工作将耗费几个月的时间。

换句话说，这一列表并不是万能的，可以直接应用在所有类型的开发环境中。我们需要将检查表与系统功能进行交叉比对，以确认共同的部分。只有这样处理，开发人员才能知道哪部分可以放下，哪部分需要加强关注。

从长远来看，安全编码检查表本身是不答案。它用来涵盖所有平台的必须代码数量高得离谱。这就意味着，为了开发列表百分之百兼容系统的应用，即使最简单的“世界，你好!”也需要花费几星期的时间。

真正的答案应该是设计开发框架和系统安全功能。这样，开发人员就可以建立属于自己的安全框架了。遵循安全编码实践指南这么做会提高整个软件包的长期安全性。

最后的思考

正如我前面提到的，大家对软件中的漏洞有很多可说的。你认为OWASP所做的工作能普及么?你是否会选择使用该检查表?

未经允许不得转载：DOIT » 安全编码指南是解决软件漏洞问题的关键？