程序员的生存之战

引言

根据 Verizon Business Risk Team 发布 的 2008 年数据泄露研究报告，网络犯罪分子最常攻击的类型是应用程序和软件。该研究进一步指出，此类攻击中有 73% 来自外部，利用了这些应用程序和软件中现有的漏洞。想象一下，如果您是这些应用程序的程序员之一，您会如何分享您的感受？您会觉得自己拥有这些“受损”应用程序的所有权有多么光荣？因为曾经是您和您组织珍贵资产的应用程序，现在只不过是“被黑网站”和“受损应用程序”。

研究进一步表明，约 57% 的漏洞是由编码和设计错误引起的。更残酷的事实是，平均每个应用程序有 8 个漏洞是由于编码和设计错误造成的。Gartner Group 和 Symantec 的研究表明，近 90% 的软件攻击都针对应用程序层。

警笛声在回响，灯光在闪烁，信息响亮而清晰：应用程序是攻击目标。如果说程序员们正处于战争状态，也并非夸张。请记住，如果您不规划，那么您就是计划失败。

这是一个令人严重关切的问题，因为如果这种情况持续下去，软件开发人员将失去声誉，组织将不再信任开发人员，平均市场工资可能会开始下降，因为每一次泄露不仅会导致组织声誉受损，还会给组织带来额外成本。根据研究，此类泄露造成的估计成本约为每年 1800 亿美元。

要点

让我们不再讨论这些可怕的数字，剥开洋葱，直奔主题吧！！

各位，我们传统的思维模式是“先建后修”。安全问题通常是在开发或测试的最后阶段才被解决，而且当预算紧张、项目超期时，修复安全问题甚至不值得一提。

解决这个弊病的良方是“从一开始就进行安全加固”，这可以用一个比喻来最好地理解：“如果安全是电线，那么房子建好后再布线会更难。”

这意味着在当今动态的应用程序开发环境中，应用程序安全性比以往任何时候都更加脆弱。事实上，许多应用程序安全漏洞的根源在于应用程序源代码。那么，安全编码是否能解决所有这些问题？答案是“否”，安全编码只能解决问题的一部分。许多泄露不仅仅是编码错误的结果，也是因为糟糕的设计，这凸显了在软件开发生命周期的每个阶段都应考虑安全需求。

游戏计划是什么？

应用程序开发是在功能需求与业务需求、资源与截止日期之间取得微妙平衡；但现在，它也应该是安全与风险之间的微妙平衡。安全现在是软件的属性之一，就像可用性、性能、可靠性、可伸缩性一样，并且有资格获得与其他属性同等的尊重。

"Security is just another attribute of software like usability,
performance, reliability and scalability. The idea of incorporating security
into the SDLC begins with the evaluating the relative importance of this
attribute and then going on to incorporating controls in line with that" 
	- Tallah Mir Sr. Program Manager - Microsoft 

承认这些事实，将 SDLC 阶段融入安全考虑是正确的方法。

要求

如果您不了解自己构建了什么，您如何保护应用程序？您了解您的应用程序吗？

一个好的起点是技术和需求规范。了解用于构建应用程序的代码符合“了解您的应用程序”这四个安全原则之一。在需求规范阶段，提出以下问题：

1. 有哪些技术安全方面的考虑？
2. 是否有任何业务模型安全方面的考虑？
3. 系统面临的主要威胁是什么？

架构 / 设计

没有人会因为错误的原因而进行设计。记住，集思广益。从第一天起就让安全风险团队参与进来。思考如何将安全需求设计进去？可能会出现什么问题？设计面临的主要威胁是什么？考虑以下设计原则：

原理	含义	示例
机制经济性	保持设计简单且复杂度低	模块化代码，集中式服务
故障安全默认	默认拒绝访问，明确授予	拒绝交易
完全媒介或强制访问控制	每次主体请求访问对象时都检查权限	凭证不缓存
开放设计	设计不是秘密	流行的加密算法
权限分离	完成任务需要多个条件	分拆密钥，分隔功能
最小权限或酌情访问控制	权限最小化，用户明确授予	非管理员账户，基于需要了解的原则
最少通用机制	不与一个以上的用户/进程/角色共享通用机制	基于角色的安全
生理可接受性	应将安全机制传达给最终用户，以便于使用和接受	帮助对话框，吸引人的图标

编码

在编码过程中，确保代码健壮且安全。采用最悲观的方法，“不信任任何东西”或“纵深防御”。例如，在输入时不要依赖内容，不要假设用户输入正确的信息。记住黄金法则：“有疑问，就检查！！”确定代码面临的主要威胁是什么？

在决定用哪种编程语言编码之前，先确定该语言的安全特性。有趣的是，每种编程语言在效率和安全性之间都有权衡。C 和 C++ 提供了效率和速度，但代码对安全问题关注甚少。了解编码中可能出现什么问题对于解决安全问题很重要。请记住：

"没有哪种语言能防止不安全的代码，尽管有些语言特性可以帮助或阻碍有安全意识的开发人员。"

-Chris Shiflett

在采用安全性的各个阶段时，请谨慎选择开发方法。我们应该使用哪种方法，瀑布、迭代、螺旋、极限还是敏捷？这些方法是否足够灵活，能够将我们的安全考虑纳入每个阶段？

总而言之，您无法仅凭规则来创建安全可靠的应用程序和软件。安全应用程序和软件开发的原则适用于各种开发方法和编程语言。

测试

存在几种不同类型和级别的测试，我在此不再详述。 suffice to say，通过 SAT（安全验收测试）来增强 UAT（用户验收测试）。UAT 表明我们一切 OK，SAT 则证明我们一切 SAFE。

底线：提防大灰狼

"In the 80's we wired the world with cables and in the
90's we wired the world with the computer networks. Today we are wiring the
world with the application (softwares).... Having a skilled professional
capable of designing, developing and deploying secure software is not critical
to this evolving world" - Mark Curphey, Director & Project Unit Manager Microsoft 
and Founder of OWASP (Open Web Application Security Project)

重要的是要记住，除了变化本身，没有什么是永恒的。如果您不改变，您很可能无法生存太久！！！！

参考文献

• White Hat 网站安全统计报告 http://www.whitehatsec.com/home/assets/WPStatsreport_100107.pdf
• 应用程序安全的三大领域 http://www.secureconsulting.net/2010/01/the_three_domains_of_applicati.html
• WASC 项目 - Web 应用程序安全统计
• http://projects.webappsec.org/Web-Application-Security-Statistics
• 关于提高应用程序安全意识的论文 - SANS 学院信息安全阅读室网站