1.2.3 应用程序安全所面临的问题

1.2.3  应用程序安全所面临的问题

由于“软件是计算机安全中的主要问题”的观点是最近才提出来的，因此背景各异的人们都在研究这个问题。在许多安全工具供应商的带领下，一些从事网络安全的人在许多安全工具供应商的支持下已经进行了艰苦的工作，并且花费了大量的市场宣传费以打造“应用程序安全”（application security）这一术语，用它描述软件安全的概念。有多种原因说明，我们应该审慎地使用应用程序安全这一术语。我个人的意见是，使用术语软件安全，而不是术语应用程序安全，特别是在讨论使安全成为软件开发必需的组成部分这个观点的时候。下面是这样做的理由。
问题之一是，术语应用程序安全对不同的人意味着不同的含义。在许多情形中，它所指的意思是在软件被建造好了之后进行的软件保护。虽然软件保护是一个很重要的概念，但是保护没有缺点的东西总是比保护布满弱点的东西要容易得多。

考虑下面的问题“保护软件最有效的方法是什么？”，这将有助于澄清软件安全和应用程序安全的意义。一方面，软件安全指的是建造安全的软件：设计安全的软件，确保软件是安全的，以及培训软件开发人员、架构人员和用户如何使安全成为软件开发必需的组成部分。另一方面，应用程序安全指的是，在完成开发之后，以马后炮的形式来保护软件和运行软件的系统。其中的重要问题包括沙盒代码（就像Java虚拟机所做的那样）、抵御恶意代码、混淆代码、锁定可执行文件、监视程序的运行（特别是输入）、用技术来增强软件使用的策略，以及处理可扩展的系统。

通过 “渗透和打补丁”以及输入过滤（试图阻挡恶意输入）之类的标准方法，以及通常的以被动反应的方式来提供值的方法，应用程序安全自然地根据以网络为中心的方法来实现安全（参见下一个文本框——应用程序安全测试工具：好还是差？）。简单地说，应用程序安全主要是查找和修补已知的安全问题——它们在实际应用系统中已经被利用，常用的方法是过滤危险的输入以避免破坏软件。软件安全——设计、建造和测试安全的软件的方法——确定和解决软件本身的问题。通过这种方法，软件安全人员试图建造能够主动地抵御攻击的软件。我举一个实际的例子：虽然通过观察到达端口80的HTTP数据流来阻止缓冲区溢出攻击的方法有一些使用价值，而一种更好的方法是修正出错的代码，以完全避免缓冲区溢出。

我认为术语应用程序安全的另一个问题是，它限制了软件安全的范围，这是毫无必要的。当然，应用程序存在安全问题，首当其冲的是基于Web的应用程序。但是，如果往后退一步，就会发现，我们还有比出错的Web应用程序更严重的问题。想一想，无线设备、手机、个人数字助理、浏览器、操作系统、路由器、服务器、个人电脑、公共密钥基础设施系统以及防火墙所具有的共同点是什么？答案是“软件”。这真是一个有趣且范围广泛的清单。它涵盖了从消费设备到基础设施项目到安全设施本身的所有内容。真正的攻击者追寻着糟糕的软件进行攻击——而不管这些软件位于何处，对此我们不应该感到吃惊。仅仅盯着“应用程序”的代码这种短视的观点忽视了更大问题。这就是我喜欢把这个领域叫做软件安全的原因。

在大型企业中，考虑到选择简单的词汇所带来的影响是很重要的。当一个大型机构开始设立一个应用程序开发项目时，将包括许多不同的小组：系统人员、网络人员、体系结构小组以及一大群应用程序开发人员。如果安全小组采用了应用程序安全的观点，他们就可能仅仅把一些供应商或者产品推给应用程序开发人员（VB.NET实现人员位于软件食物链的底层）。与此相反，软件安全的观点要求应用程序人员和那些中间件的架构人员（他们负责特别容易出现设计瑕疵的核心“服务”代码）都仔细地审核自己的工作。（当然，应用程序代码和它所依赖的中间件都可能包含缺陷。）

像应用程序开发组和体系结构组这样的子机构的工作分工非常明确，即使所选择的应用程序安全方案的供应商或者产品最后在应用程序中找出缺点，其他小组的人员也可能推卸责任：“哦，你应该跟架构人员谈谈。”在这种情形中，很可能没有人真正理会安全问题——特别是体系结构和“真正的”代码一般都已经定案难改，而且在还没有招聘到VB.NET实现人员之前，架构人员就已经被分配到了其他的项目中。

1应用程序安全测试工具：好还是差？   
应用程序安全的测试产品是作为解决不安全的软件问题的方案来销售的。令人遗憾的是，这些第一代的方案并不像他们所吹嘘的那样好。它们能够帮助

我们诊断、描述和演示问题，但是它们在修改问题方面的作用很有限。今天的应用程序安全产品将软件应用程序作为易出错的“黑盒”来对待，必须进

行探测以阻止安全灾难。遗憾的是，这种方法太简单。软件测试必须有计划，并应该以软件需求和正在测试的代码的体系结构为基础。一旦完成了代码

，就不能通过辛苦地查找和删除缺陷来“进行必需的测试”。软件安全的情形也与此相同；运行一些预先设计好的测试，比如通过给程序发送不正常的

输入流来“模拟恶意黑客”，并不能起到什么作用。真正的黑客并不会简单地用输入“抚摸”程序，据此发现程序中的问题。攻击者会剖析程序，确定

它是如何工作的，并且做一些用户不会做的操作，使程序出现异常。出现这种问题的根本原因是，黑盒测试方法，包括应用程序安全测试工具，都只是

以由外及内的方式来解决软件的表面问题，而没有深入软件的内部，没有从内部来保障软件的安全。
测量糟糕程度的表
据说，应用程序安全测试工具能够告诉你软件安全的状态——即你是否处于大麻烦中。就是说，如果你的软件没有通过这些预先设计的任何测试，你就

需要进行一些严格的安全工作。这些工具有助于揭示已知的问题。但是，如果你成功地通过了所有的测试，那么除了知道这一点，你并未获得更多的信

息。用更简单的术语来表述就是，应用程序安全测试工具是一种“测量糟糕程度的表”，如图1-7所示。它们提供了从“大麻烦”到“不确定”之间的

一个读数，但是它们没有提供关于“安全”程度的读数。大多数存在于体系结构和代码中的弱点都超出了预先设计的测试所能检测到的范围，因此，通

过了所有的测试并没有说明软件是安全的。（当然，知道你处于大麻烦中也是有用的！）

图1-7  测量糟糕程度的表
应用程序安全测试工具的另一个主要缺点是，它们仅仅关注应用程序通过端口80所提供的输入。仅仅依赖应用程序进行通信的协议，并据此来理解和测

试一个复杂的程序只能提供很肤浅的分析。虽然许多的攻击确实是通过HTTP来实施的，但是这只是一类安全问题。首先，除了HTTP外，现代程序还有许

多其他的输入形式：比如SSL、环境变量、外部库、使用其他协议的分布式组件等。除了程序输入，软件安全还必须考虑体系结构的稳固性、数据安全、

访问控制、软件环境，以及任何其他方面的问题，这些取决于应用程序本身。可以有效地探测每一种可能的应用程序的预设测试是不存在的。

应用程序安全工具的唯一有效用途是测试商业现货软件。简单的动态检查设置了合理的最低收货标准。如果发送给你的软件没有通过简单的测试，你就可

以拒绝接收或者采取措施来监测它的行为。在最终分析中，应用程序安全确实提供了一些有价值的信息。刚开始考虑软件安全问题的机构可以用它们来作

为测量糟糕程度的表，以帮助确定他们的问题有多大。得到的结果可以警告相关的各方：软件存在问题，并促使他们采取措施以解决问题。但是，使用这

些工具所能获得的最好的结果也只是实现粗略的分析。解决它们所揭露出来的问题，首先就需要建造更好的软件——无论你是否是这个被测试软件的建造

者。