安全编程 开发安全的程序 正确的理念是成功的一半（2）

look_w

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 还是具有专利权的 － 其开发人员是否知道如何编写安全的程序。
如果您需要安全的程序，那么使用 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 应用程序”）分门别类。原因是什么呢？今天的应用程序正不断相互联系，它们由许多不同的部分组成。其结果是，您的“一个”应用程序可能有几个不同的部分，每个部分都属于不同的一类，这是十分可能的！但是，我认为更好的做法是，了解如何在任何情况下都能开发安全的应用程序，并随后注意何时应用特定的指导原则。