Board logo

标题: 安全编程 开发安全的程序 正确的理念是成功的一半(2) [打印本页]

作者: look_w    时间: 2018-4-18 20:56     标题: 安全编程 开发安全的程序 正确的理念是成功的一半(2)

FLOSS 会使我们安全吗?自由/开放源码软件程序是带有某种许可证的程序,这样的许可证允许用户以任何目的自由地运行程序,自由地研究和修改程序以及自由地重新分发原始程序副本或修改过的程序副本(而不必向以前的开发人员支付版税)。FLOSS 的同义词包括开放源码软件(OSS),大写时是“自由软件(Free Software)”(FS)以及 OSS/FS。“自由软件”和“开放源码软件”可在本文中互换使用,但是推荐使用“FLOSS”,因为它包含了这两个术语。典型的 FLOSS 程序都是由开发人员社区开发的,他们一起工作并评审彼此的工作。Linux 内核是 FLOSS,Apache Web 服务器和许多其它程序也是 FLOSS;FLOSS 正逐渐在许多市场特殊领域流行起来。
人们可以评审 FLOSS 程序的源代码,这样会如何影响安全性存在着激烈辩论。由于受到大众所有可能的详细审查,所以 FLOSS 会更安全吗?或者,FLOSS 是否会更不安全,因为攻击者获得了更多的信息 - 这会使得进行对程序的攻击更容易吗?
这些问题开始有了答案,与象“FLOSS 总是比较安全的”这样的简单声明相比,这些答案更为细致且更复杂。确实有事实证明 FLOSS        比具有专利权的软件安全。例如,据报告 FLOSS OpenBSD 操作系统的安全性漏洞比 Microsoft Windows 少得多。但是有一个合理的“反诉”:由于 Windows 用户比较多,所以对 Windows 的攻击就可能比较多,这意味着更有可能发现 Windows 的安全性漏洞。这就是比较的全部内容吗?很值得怀疑,不过这也显示出作同等对比是多么困难。      
一个更佳的示例是 Apache Web 服务器:它比 Microsoft 的具有专利权的 IIS Web 服务器流行得多,但是 Apache 的严重安全性漏洞却比 IIS 少。请参阅我的论文“Why OSS/FS? Look at the Numbers”(在 中)获取有关 FLOSS 的更多统计信息,包括安全性统计信息。      
还有一点很清楚,攻击者实际上并不需要源代码。只要研究可获得的所有 Microsoft Windows 漏洞利用就可以了!更重要的是,如果攻击者需要源代码,那么他们会使用反编译器,来重新创建源代码,这样重新创建的源代码对攻击目的而言足够了。
但是答案也并非就是“FLOSS 总是比较安全的”。毕竟,您可以将具有专利权的程序的许可证更改成 FLOSS,而不更改其代码,而它不会突然就变得更安全。相反,有几个因素看来是使 FLOSS 程序拥有良好的安全性所必不可少的:
简而言之,程序是否安全最重要的因素是 - 不管它是 FLOSS 还是具有专利权的 - 其开发人员是否知道如何编写安全的程序。
如果您需要安全的程序,那么使用 FLOSS 程序就相当合理 - 但您需要以某种方式评估它以确定它对于您的目的是否足够安全。
确定您的安全性需求在您可以确定程序是否安全之前,需要先确切地确定其安全性需求是什么。事实上,有关安全性的实际问题之一是安全性需求会根据不同的程序和不同的环境而迥然不同。文档查看器或编辑器(如字处理器)可能需要确保查看数据不会使程序运行任意命令。购物车需要确保顾客不能自己定价,而且顾客不能查看有关其他顾客的信息等等。
事实上您可以使用一个国际标准来正式确定安全性需求并确定它们是否满足要求。这个国际标准的正式标识符是 ISO/IEC 15408:1999,但人们都称之为“通用标准(Common Criteria,CC)”。
有些合同特别要求您使用 CC 的所有细节,这样的话,您需要知道的就要比本文所涉及的多得多。但对于许多情况,帮助您确定安全性需求所需的全部就是一个非正式的简化方法。所以,我将根据 CC,来描述一个用于确定安全性需求的经过简化的方法:
即使您在非正式地这样做,也请写下您的结果 - 它们以后也可以向您和您的用户提供帮助。
安全性环境程序实际上不会在真空中工作 - 在某个环境中是安全的程序可能在另一个环境中就不安全了。因此,您必须确定您的程序要在什么样的环境(或多种环境)下工作。特别地,请考虑:
安全性目标一旦您知道了身处什么环境;就可以确定您的安全性目标,它们基本上是高级需求。典型的安全性目标涉及多个方面,比如:
通常,在您确定了安全性目标时,您的程序单靠自己还不能完成某些事情。例如,可能您正在运行的操作系统需要进行加强,或者可能您要依靠一些外部认证系统。这样的话,您就需要确定这些环境需求并确保您告诉了用户如何使这些需求成为现实。然后您可以将精力集中在您程序的安全性需求上。
功能性需求和保证需求一旦知道了程序的安全性目标,就可以通过更详细地填充其内容来确定安全性需求。CC 确定了两类主要的安全性需求:保证需求和功能性需求。事实上,CC 的大多数内容是一个可能的保证需求和功能性需求的列表,您可以针对给定的程序从中进行选取。
保证需求是用来确保程序完成它该做的事情 - 而不做别的事 - 的过程。这可能包括评审程序文档以查看其前后的一致性、测试安全性机制以确保它们按计划工作,或者创建并运行渗透测试(为设法攻破程序而专门设计的测试)。CC 预先创建了几组保证需求,但是如果其它保证措施有助于您满足要求,那么也可以自由使用这些措施。例如,您可以使用工具在您的源代码中搜索可能的安全性问题(这些工具称为“源代码扫描工具”) - 即使它不是 CC 中的特定保证需求。      
功能性需求是程序为实现安全性目标所执行的功能。也许程序会检查密码以认证用户,或者对数据加密以将它隐藏等等。通常,只有“授权”用户可以完成某些操作 - 所以请考虑程序应该如何确定谁获得了授权。      
下一步是什么?那么,一旦知道了程序必须做的事情,这就够了吗?不。只要大致阅读已知的安全性漏洞列表(如 Bugtraq、CERT 或 CVE)就可以知道,当今的大多数安全性漏洞都是由相对小的一组常见实现错误引起的。这些错误没有单一的标准术语,但是还是有常见的短语来描述它们,如“不能验证输入(failing to validate input)”、“缓冲区溢出(buffer overflow)”以及“竞态状态(race condition)”等等。遗憾的是,大多数开发人员对于这些常见错误是什么没有任何概念,而且他们重复着别人以前已经犯过的错误。
本专栏未来的文章将深入讨论这些常见错误是什么,而且更重要的是,如何避免犯这样的错误。在许多情况下,避免这样错误的方法是细致加简单 - 但是如果您不知道如何避免错误,那么就有可能重犯这样的错误。
在本专栏中,我一般不会设法将多种不同的应用程序(如“Web 应用程序”、“基础结构组件”、“本地应用程序”或“setuid 应用程序”)分门别类。原因是什么呢?今天的应用程序正不断相互联系,它们由许多不同的部分组成。其结果是,您的“一个”应用程序可能有几个不同的部分,每个部分都属于不同的一类,这是十分可能的!但是,我认为更好的做法是,了解如何在任何情况下都能开发安全的应用程序,并随后注意何时应用特定的指导原则。




欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0