如何保证Web应用程序安全性？

Web应用程序是当今多数企业应用的前沿阵地。Web应用程序在一个复杂的混合性架构中可以发挥多种不同的功能。其涉及范围极广，从在最新的云技术上运行的面向服务的方案，到较老的多层Web应用程序，再到准许客户访问大型主机上老应用程序的Web入口，都有其应用。

管理与这些复杂的Web应用程序相关的风险是公司的必然要求，而且运行这些Web应用程序的底层代码的安全性直接影响到公司应用程序可用数据的风险态势。不幸的是，开发可重复的高效Web应用程序的安全实践并非一项简单任务。许多单位试图运用后生产(post-production)解决方案来提供安全控制，如Web应用防火墙和入侵防御系统等。

但是一直等到生命周期的生产阶段才部署安全机制有点儿太迟，其效用也太小。设计或架构问题在生命周期的早期阶段更容易解决，如果等到应用程序投入生产之后再“亡羊补 牢”,其所花费的成本将极其高昂。Web应用程序的安全漏洞可导致数据泄露、违反策略，而且，在部署后再打补丁或进行全面的代码修复都会极大地增加总成本。

为保证效益和效率，Web应用程序的安全必须从需求的定义阶段开始，直至最后的接收阶段。这种方法要求全体设计人员在整个过程中能够作为一个团队通力合作。在实施和测试等阶段，使用遵循策略的自动化工具能够支持可重复的测试，并且随着测试过程的标准化可以使开发周期更快。

在开发过程的最初阶段就着手构建安全性未必很复杂。在整个开发周期实施安全检查和平衡，可以实现更快的发布周期，并可以极大地减少Web应用程序的漏洞。

在开发周期的后期实施安全测试的高昂成本

将安全检查点加入到开发过程中，确实可以减少总体交付时间。这听起来有点儿违反直觉，但是，在Web应用程序部署进入生产阶段之后，与纠正设计错误和代码错误相关的成本是极其高昂的。

例如，在许多开发环境中，安全和审核专家往往出现在开发周期结束之时。此时，应用程序已经完成，任何延误都被看作是多余的瓶颈。企业方面要求软件产品快速推出，这种巨大的压力意味着可能会忽略安全控制，导致Web应用程序没有经过恰当的安全审查。在这种时间极端敏感的环境，即使扫描工具报告了大量的漏洞但却没有经过验证，也没有确定其优先次序，这种扫描也是弊大于利。

在开发过程的后期进行安全审计，而不是在整个开发周期中协力完成，会导致发布时间延迟，特别是在发现了某些严重的错误时尤其如此。在开发周期的后期修复设计和编码错误的成本远远高于早期发现错误所花费的成本。根据美国国家科学基金会的一项研究估计，如果在需求和设计阶段发现和纠正了严重的软件问题，其成本要比将软件投入生产之后再发现问题所花费的成本大约低100倍。

在Web应用程序中构建安全性时，在多数情况下，其目标并不是构建固若金汤的Web应用程序，或者清除每一处可能的漏洞。相反，目标应当是将所要求的特性与经认可的关于Web应用程序的风险预测匹配起来。在整个Web应用程序的开发周期中，其目标应当是实现软件担保，即与特定Web应用程序相适应的功能和敏感水平，能够有理由保证软件将会持续地实现其所要求的特性，即使软件遭受攻击也能够如此。

整合方法的好处

当来自不同小组的开发人员作为一个团队协同工作时，就会造就Web应用程序开发过程的高效率。虽然安全专业人员常常慨叹商务主管完全不理解软件风险，但是安全专业人员熟悉商业风险也很重要。通过适当的软件担保水平来构建Web应用程序，要求在商业需要、可用性和安全性之间进行风险管理权衡。为了达到适当的平衡，必须收集所有开发人员的需求。

从软件开发的开始阶段，需求定义和应用程序的设计就应当考虑安全需求以及功能需求和商业需要。在编写代码之前，这种信息就应当传达给设计师和软件开发人员。这种方法可以防止多数甚至是全部安全设计漏洞和架构漏洞。

然而，关注安全的软件设计并不是排除与Web应用程序相关的所有漏洞。开发人员自身必须接受关于安全编码技术的培训，以确保在应用程序的设计期间，并不 会带来安全漏洞。让开发人员洞察开发语言和运行环境的安全方法可以支持更好的编码实践，并会使最终的Web应用程序出现的错误更少。将安全性纳入到设计过程中的另一个效率上的利益是，能够在需求和设计期间建立误用情形。在测试和接收阶段这样做可以节省时间，并有助于消除瓶颈。

整合性合成测试的好处

软件测试的整合性的合成分析方法可以更大地提升效率。集成开发环境的特定插件在发现用户的编码错误时会向编码人员发出警告。静态分析，也称为“白盒”测试，在将不同的模块组装成最终的产品之前，开发人员和审计人员就对其使用此技术。静态分析在代码水平上提供了一种内部人员对应用程序的检查分析。静态分析对于发现语法错误和代码水平的缺陷是很有效的，但并不适于决定一个缺陷是否会导致可利用的漏洞。

动态分析和人工渗透测试对于验证应用程序是否容易受到攻击是有效的。它也被称为“黑盒测试”，主要展示的是外部人员对应用程序的检查分析，可以对投入生产的应用程序进行深入检查，查看攻击者是否容易利用其漏洞。然而，动态测试技术仅能用于软件开发的后期，只能在生成后阶段。动态测试的另一个局限性是它很难找出代码中导致漏洞的代码源。

这就是将静态测试和动态测试结合起来以“灰盒”或组合的方法进行混合测试的原因。通过将代码水平的内部检查和动态的外部检查结果结合起来，就可以充分利用两种技术的长处。使用静态和动态评估工具可以使管理人员和开发人员区分应用程序、模块、漏洞的优先次序，并首先处理影响最大的问题。组合分析方法的另外一个好处是动态测试确认的漏洞可 以用静态工具追溯到特定的代码行或代码块。这便有利于测试和开发团队进行合作性交流，并使得安全和测试专家更容易向开发人员提供具体的可操作的纠错指导。

将安全性构建到软件的生命周期中：实用方法

构建安全性需要人员、过程以及技术、方法。虽然有大量的工具可有助于自动化地强化Web应用程序的安全，但是，如果没有恰当的过程和训练有素的人员来创建、测试Web应用程序，那么，任何工具都不会真正有效。

这个过程应当包括一个正式的软件开发周期及所公布的策略。此外，为所有的开发人员建立角色，并且指派检查和监管责任也是很重要的。安全和业务在软件开发周期的每一个阶段都应当得到表现，从而可以在每一个步骤处理风险管理。

在软件的整个开发周期，一个有益的永恒主题就是教育。教育对于开发人员是很重要的，它对于Web应用程序开发所涉及到的全体人员都很有益。因为安全意识 既需要从上而下，也需要从下而上。不要低估教育管理人员认识到Web应用程序的漏洞如何影响企业的重要性。告诉一位管理人员Web应用程序易于遭受跨站请 求伪造(CSRF)可能会令他感到茫然，但是如果向他展示软件错误如何会导致客户数据的泄露，就能够有助于使其意识到不安全的Web应用程序所造成的切实 后果。应该准备特定的案例和度量标准用以阐明潜在的各种成本节约。例如，在开发人员检查其代码之前，就演示对开发人员的培训和IDE的静态分析插件投资可 以阻止软件应用中的数据泄露根源。

审计人员和评估人员可以从学 习常见的编码错误、后果评估以及与Web应用程序“生态系统”(包括后端的支撑系统、现有的安全控制以及属于Web应用程序环境的任何服务或应用程序)有关的依赖关系中获益。测试者及质量评价专家应当熟知误用情形，并且知道误用情形是如何区别于标准的应用的，还要知道如何解释安全测试结果，并能够按照需要 对结果区分优先次序。

关注软件开发周期中的具体步骤，在这些步骤中存在着增加效率同时又可以贯彻安全性和风险管理的机会。

需求

Web应用程序的设计者对于定义功能和业务需求非常熟悉，但是未必理解如何定义安全需求。此时，整个团队需要协同工作，决定哪些安全控制对最终的Web应用程序至关重要。

将安全性集成到需求阶段的步骤

1. 根据公司策略、合规和规章要求，讨论并定义安全需求。

2. 安全和审计团队应当评估业务需求和Web应用程序的功能，并且在测试和接受期间开始制定误用案例(误用情形)。

其好处有两方面，一是提前清除或减少安全或违规问题，二是减少部署时间。

架构和设计

由于已经定义了Web应用程序的架构和设计方案，下一步就需要评估安全问题。正是在这个阶段，成本高昂的、难以纠正的安全问题可以在其最易于解决的时间 修复。为了防止损失惨重的错误，应当从性能和安全两个方面评估程序的架构。由于编制了详细的设计规范，因而可以向开发人员展示出应当包括哪些安全控制，以及应用程序的组件如何与完整的Web应用程序进行交互。

将安全性集成到架构和设计阶段的步骤

1. 对于所建议的架构和部署环境执行风险评估，以决定设计是否会带来风险。

2. 评估应用程序与原有系统进行交互时的安全意义和风险，以及不同的组件、层或系统之间的数据流的安全问题。

3. 评述在实施或部署阶段需要解决的任何具体的暴露问题(即依赖于应用程序的部署方式和部署位置的漏洞)。

4. 考虑依赖关系以及与混搭关系、SOA及合伙服务的交互所引起的漏洞。将最终的设计交付安全和审计，以确定安全测试计划和误用情形。

其好处体现在五个方面：

1. 可以精心协调风险评估分析过程和可重用的风险评估模型。

2. 可以在早期阶段确定由架构环境或部署环境所带来的风险。

3. 可重用的误用案例可以节省测试阶段的时间。

4. 减少特定的设计漏洞。

5. 如果有必要，可以调整或变更带来风险的架构限制，如果无法完全清除风险,也可以用补偿性控制来定义减轻风险的策略。

代码执行与编译

在开发人员开始编写代码时，他们对安全控制必须拥有一套完整的风险评估设计和清晰指南，或通过经认可的服务来使用这种安全控制。集成到IDE中的自动化静态代码工具可以在编写代码时向开发人员提供检查和指南。自动化的工具还可在编译期间用于对照策略模板检查代码是否违规，并可以深入查看代码水平的安全问题。

将安全性集成到代码执行和编译阶段的步骤

1. 安装可与集成开发环境整合到一起的静态源码检查工具。

2. 作为一种选择，开发人员在交付代码之前可以用独立的编码工具来执行自动化的代码检查。

3. 安全和审核团队抽查代码模块，看其是否遵循合规要求，并在编译之前使用自动化的或手动的代码检查来检查其安全风险。

4. 在编译过程中，执行自动化的静态代码扫描，查找安全问题和策略的遵循情况。

5. 使用工具跟踪开发人员的编码错误，并对其带来的安全风险提供解释性反馈和原因说明。

这会带来如下的好处：

1. 可将更清洁的或漏洞更少的代码提交给质量评价人员。

2. 随着时间的推移开人人员可以提升安全编码能力。

3. 可重用策略可以提升风险分析的正确性。

4. 在测试阶段发现的编码错误或漏洞更少，并会使开发周期更短。

质量评价/测试

用于测试应用程序的具体安全工具范围很广，其中有可以评估完整应用程序的独立解决方案和服务，更有完全集成的套件,这种套件可以提供测试和对从教育到实施等多个阶段的支持。集成的方案可以为那些对可重复的Web应用程序的安全周期表现成熟的公司提供多个阶段的支持。集成套件可以在进程中的多个时点上实施，并可为持续的改善提供尺度和反馈。

那么，在质量评价和测试阶段，应采取哪些集成安全和改善安全的步骤呢?

1. 专注于发现某些资源的最重要问题。

2. 在一个包括现有的补救控制(如防火墙和IPS)的应用架构中验证这些测试发现。

3. 根据安全性和业务需要，区分所发现的漏洞的优先次序。

4. 对于代码行或其所依赖的API、服务、库等提出修复建议。

其好处也是显而易见的：1. 应用程序开发人员之间可以更好地交流。2. 似是而非的东西更少。3. 修复周期更快。

部署/投产

Web应用程序的安全性并不会终止于应用程序的部署阶段。一旦Web应用程序投产，还应当实施其它测试和监视，用以确保数据和服务受到保护。实际的 Web应用程序的自动安全监视能够确保应用程序正在如所期望的那样运行，并且不会泄露信息从而造成风险。监视可由内部人员完成，也可外包给能够全天候监视 应用程序的外部供应商。

在部署和投产阶段集成和改善安全性的步骤：

1. 监视误用情况，其目的是为了确定测试中所谓的“不会被利用的漏洞”在投产后真得不会被利用。

2. 监视数据泄露，其目的是为了查找被错误地使用、发送或存储的所有地方。

3. 将部署前的风险评估与投产后的暴露范围进行比较，并向测试团队提供反馈。

4. 实施Web应用防火墙、IPS或其它的补救措施，其目的是为了减轻代码修复之前的暴露程度，或是为了符合新的安全规范。

其好处有如下几个方面：

1. 改善能够成功实施的漏洞利用的知识库，从而改善在静态和动态测试期间的扫描效益。

2. 发现并阻止应用程序的误用情况。

3. 在动态测试和投产中的应用程序控制(如Web应用防火墙或IPS)之间实现更好的集成。

4. 满足再次编写代码之前的合规需要。

5. 使用反馈机制实现持续的改善。

小结

保障Web应用程序的安全未必意味着延长开发周期。只要对所有开发人员进行良好的教育，并采取清晰且可重复的构建过程，企业就可以用一种高效而合作性的方式将安全和风险纳入到开发过程中。

将安全构建到Web应用程序的交付周期中确实需要一种合作性的方法，需要将人员、过程和技术集成到一起。虽然Web应用程序安全工具和套件有助于过程的改进，但它们并非万能药。为获得最大利益，应当考虑选择能够理解完整开发周期的Web应用程序安全工具厂商，还要有能在开发过程的多个阶段提供支持的工具。