1.2 Web应用程序中存在的风险及预防

由于网络技术日趋成熟，黑客们也将注意力从以往对网络服务器的攻击逐步转移到了对Web应用的攻击上。根据Gartner的最新调查，信息安全攻击有75%都是发生在Web应用而非网络层面上。同时，数据也显示，2/3的Web站点都相当脆弱，易受攻击。然而现实是，绝大多数企业将大量的投资花费在网络和服务器的安全上，没有从真正意义上保证Web应用本身的安全，给黑客以可乘之机。

Web应用程序安全无疑是当务之急，也是值得关注的话题。对相关各方而言，这一问题都至关重要。这里的相关各方包括互联网业务收入日益增长的公司、向Web应用程序托付敏感信息的用户，以及通过窃取支付信息或入侵银行账户偷窃巨额资金的犯罪分子。可靠的信誉也非常重要，没人愿意与不安全的Web站点进行交易，也没有组织愿意披露有关其安全方面的漏洞或违规行为的详细情况。因此，获取当前Web应用程序安全状况的可靠信息不可小视。

1.2.1 Web应用程序的安全套接层（SSL）应用

与任何新兴技术一样，Web应用程序也会带来一系列新的安全方面的漏洞。这些常见的缺陷也在“与时俱进”，一些开发人员在开发现有应用程序时未曾考虑到的攻击方式都相继出现了。由于安全意识的加强，一些问题已经得到解决。新技术的开发也会引入新的漏洞。Web浏览器软件的改进基本上消除了某些缺陷。

对Web应用程序而言，安全确实是个“问题”。查询一个典型的应用程序的帮助页面，其中的内容会向你保证该应用程序确实是安全的。大多数Web应用程序都声称其安全可靠，因为它们使用SSL（Secure Socket Layer, SSL安全套接层）。

它使用128位安全套接层技术设计，是为网络通信提供安全及数据完整性的一种安全协议。SSL在传输层对网络连接进行加密，可防止未授权用户查看您的任何信息。它提供以下服务。

（1）认证用户和服务器，确保数据发送到正确的客户机和服务器。

（2）加密数据以防止数据中途被窃取。

（3）维护数据的完整性，确保数据在传输过程中不被改变。

您可以放心使用本站点，我们绝对保障您的数据安全。Web应用程序常常要求用户核实站点证书，并想方设法让用户相信其所采用的先进加密协议无懈可击，从而说服用户放心地向其提供个人信息。

TCP/IP协议栈中的安全机制如图1-2所示。

此外，各种组织还声称他们遵循支付卡行业（PCI）标准，以消除用户对安全问题的担忧。

我们极其注重安全，每天扫描Web站点，以确保始终遵循PCI标准，并免受黑客攻击。下面的标志上显示了最近扫描日期，请放心访问该Web站点。

实际上，大多数Web应用程序并不安全，虽然SSL已得到广泛使用，且会定期进行PCI扫描。常见的Web应用程序漏洞类型有以下几种。

（1）跨站点脚本（94%）。攻击者可利用该漏洞攻击应用程序的其他用户、访问其信息、代表他们执行未授权操作，或者向其发动其他攻击。

（2）跨站点请求伪造（92%）。利用这种漏洞，攻击者可以诱使用户在无意中使用自己的用户权限对应用程序执行操作。恶意Web站点可以利用该漏洞，通过受害用户与应用程序进行交互，执行用户并不打算执行的操作。

（3）信息泄露（78%）。这一问题包括应用程序泄露敏感信息，攻击者利用这些敏感信息通过有缺陷的错误处理或其他行为攻击应用程序。

（4）不完善的访问控制措施（71%）。这一问题涉及的情况包括应用程序无法为数据和功能提供全面保护，攻击者可以查看其他用户保存在服务器中的敏感信息，或者执行特权操作。（5）不完善的身份验证措施（62%）。这类漏洞包括应用程序登录机制中的各种缺陷，可能会使攻击者破解保密性不强的密码、发动蛮力攻击或完全避开登录。

（6）SQL注入（32%）。攻击者可通过这一漏洞提交专门设计的输入，干扰应用程序与后端数据库的交互活动。攻击者能够从应用程序中提取任何数据、破坏其逻辑结构，或者在数据库服务器上执行命令。

OWASP（开放式Web应用程序安全项目组织）列出的Web应用程序漏洞排名如图1-3所示。

SSL是一种出色的技术，可为用户浏览器和Web服务器间传输的数据提供机密性与完整性保护功能。它有助于防止信息泄露，并可保证用户处理的Web服务器的安全性。但SSL并不能抵御直接针对某个应用程序的服务器或客户端组件的攻击，而许多成功的攻击都恰恰属于这种类型。

从SSL协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大都是信誉较高的大公司，因此这问题还没有充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL 3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，如只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和MasterCard两大信用卡组织制定了SET协议，为网上信用卡支付提供了全球性的标准。特别需要指出的是，SSL并不能阻止上述任何漏洞或许多其他使应用程序受到威胁的漏洞。无论是否使用SSL，大多数Web应用程序仍然存在安全漏洞。

1.2.2 Web应用程序安全的核心问题

Web应用程序为结构设计人员和开发人员提出了一系列复杂的安全问题。最安全、最有能力抵御攻击的Web应用程序是那些应用安全思想构建的应用程序。与多数分布式应用程序一样，为确保安全，Web应用程序必须解决一个根本的问题。由于应用程序无法控制客户端，用户几乎可向服务器端应用程序提交任意输入。应用程序必须假设所有输入的信息都是恶意的输入，并必须采取措施确保攻击者无法使用专门设计的输入破坏应用程序，干扰其逻辑结构与行为，并最终达到非法访问其数据和功能的目的。这个核心问题表现在以下几个方面。

（1）用户并不限于仅使用一种Web浏览器访问应用程序。大量各种各样的工具可以协助攻击Web应用程序，这些工具既可整合在浏览器中，也可独立于浏览器运作。这些工具能够提出普通浏览器无法提交的请求，并能够迅速生成大量的请求，查找和利用安全问题达到自己的目的。

（2）用户可干预客户端与服务器间传送的所有数据，包括请求参数、Cookies和HTTP信息头。可轻易避开客户端执行的任何安全控件，如输入确认验证。

（3）绝大多数针对Web应用程序的攻击都涉及向服务器提交输入，旨在引起一些应用程序设计者无法预料或不希望出现的事件。以下举例说明为实现这种目的而提交的专门设计的输入。

① 用户可按任何顺序发送请求，并可在应用程序要求之外的不同阶段不止一次提交或根本不提交参数。用户的操作可能与开发人员对用户和应用程序交互方式做出的任何假设完全不同。

② 改变由后端数据库处理的某个输入，从而注入一个恶意数据库查询以访问敏感数据。

③ 利用应用程序处理过程中的逻辑错误删除某些正常提交的参数。

④ 更改以隐藏的HTML表单字段提交的产品价格，以更低廉的价格欺诈性地购买该产品。

⑤ 修改在HTTP Cookies中传送的会话令牌，劫持另一个验证用户的会话。

输入验证是一个很复杂的问题，并且是应用程序开发人员需要解决的首要问题。然而，正确的输入验证是防御目前应用程序攻击的最有效方法之一。正确的输入验证是防止XSS、SQL注入、缓冲区溢出和其他输入攻击的有效对策。

输入验证非常复杂，因为对于应用程序之间甚至应用程序内部的输入，其有效构成没有一个统一的答案。同样，对于恶意的输入也没有一个统一的定义。更困难的是，应用程序对如何处理此输入将会影响应用的风险。例如，您是否存储用于其他应用程序的数据，或者应用程序是否接受来自其他应用程序所创建的数据源的输入？

以下做法可以增强Web应用程序的输入验证。

（1）假定所有输入都是恶意的。

开始输入验证时，首先假定所有输入都是恶意的，除非有证据表明它们并无恶意。无论输入是来自服务、共享文件、用户还是数据库，只要其来源不在可信任的范围之内，就应对输入进行验证。例如，如果调用返回字符串的外部Web服务，如何知道该服务不会执行恶意命令呢？另外，如果几个应用程序写入同一个共享数据库，您在读取数据时，如何知道该数据是否安全呢？

（2）集中式验证方法。

将输入验证策略作为应用程序设计的核心元素。考虑集中式验证方法，如通过使用共享库中的公共验证和筛选代码。这可确保验证规则应用的一致性。此外，还能减少开发的工作量，且有助于以后的维护工作。

许多情况下，不同的字段要求不同的验证方法，如要求使用专门开发的常规表达式。但是，通常可以得到验证常用字段（如电子邮件地址、标题、名称、包括邮政编码在内的通信地址，等等）的常规方法。

输入验证的集中式方法如图1-4所示。

（3）不要依赖于客户端验证。

应使用服务器端代码执行其自身的验证。如果攻击者绕过客户端或关闭客户端脚本例程（如通过禁用Java Script脚本），后果如何？使用客户端验证可以减少客户端到服务器端的往返次数，但不要依赖这种方法进行安全验证。这是一个深入彻底的防御示例。

（4）注意标准化问题。

数据的标准形式是最标准、最简单的形式。标准化是指将数据转化为标准形式的过程。文件路径和URL尤其倾向于标准化问题，许多广为人知的漏洞利用都直接源自标准化缺陷。例如，请考虑以下字符串，它以标准形式表示了文件及其路径。

c:\temp\somefi le.dat

以下字符串也可以代表同一个文件。

somefi le.dat
    c:\temp\subdir\..\somefi le.dat
    c:\temp\somefi le.dat
    ..\somefi le.dat
    c%3A%5Ctemp%5Csubdir%5C%2E%2E%5Csomefi le.dat

最后一个示例使用十六进制指定字符：

%3A代表冒号；

%5C代表反斜杠符号；

%2E代表点号。

通常，应设法避免让应用程序接受用户输入的文件名，以防止标准化问题，可以考虑其他设计方法。例如，让应用程序为用户确定文件名。如果确实需要用户输入文件名，在做出安全决策（如授予或拒绝对特定文件的访问权限）之前，应确保这些文件名具有严格定义的形式。

（5）限制、拒绝和净化输入。

输入验证的首选方法是从开始就限制允许输入的内容。按照已知的有效类型、模式和范围验证数据要比通过查找已知有害字符的数据验证方法容易。设计应用程序时，应了解应用程序需要输入什么内容。与潜在的恶意输入相比，有效数据的范围通常是更为有限的集合。然而，为了使防御更为彻底，您可能还希望拒绝已知的有害输入，然后净化输入，如图1-5所示。

要创建有效的输入验证策略，需了解以下方法及其折中方案。

① 限制输入。限制输入与允许输入有益数据类似。这是首选的输入验证方法。其思想是定义一个筛选器，根据类型、长度、格式和范围来筛选输入的数据。定义应用程序字段可以接受的数据输入，并强制应用该定义。拒绝一切有害数据。限制输入可能包括在服务器上设置字符集，以便在本地建立输入的规范格式。

② 验证数据的类型、长度、格式和范围。在适当的地方对输入数据使用强类型检查，例如，在用于操作和处理输入数据的类中，以及在数据访问例程中。例如，可以使用参数化的存储过程来访问数据，以便利用输入字段的强类型检查所带来的好处。

应该检查字符串字段的长度，在许多情况下，还应检查字符串的格式是否正确。例如，邮政编码和身份证号码等都具有明确定义的格式，可以使用常规表达式进行验证。严格的检查不仅是很好的编程习惯，还能让攻击者更难利用用户的代码。攻击者可能会通过类型检查，但长度检查会加大攻击者实施其所喜欢的攻击方式的难度。

③ 拒绝已知的有害输入。虽然不能完全依赖于这种方法，但还是应该拒绝“有害”数据。此方法通常不会像使用上述的“允许”方法那样有效，但二者结合使用可以收到最佳效果。要拒绝有害数据，需假定应用程序知道恶意输入的所有变体。请记住，字符有多种表达方式。这是“允许”方法成为首选方法的另一个原因。

虽然在应用程序已经部署、不能再做重大更改时，“拒绝”方法非常有用，但它不如“允许”方法那样可靠，因为有害数据（如可用于识别常见攻击的样式）不是保持不变的。有效数据的形式是保持不变的，但有害数据的范围是时常变化的。

④ 净化输入。净化是为了使有潜在危害的数据变得安全。如果所允许的输入范围不能保证输入数据的安全性，那么净化输入是非常有用的。净化包括从删除用户输入字符串后面的空格到去除值（以便按照文字格式处理该数据）等一切行为。

在Web应用程序中，另一个常见的净化输入示例是使用URL编码或HTML编码来包装数据，并将其作为文本而不是可执行脚本来处理。HtmlEncode方法去除HTML字符，而UrlEncode方法对URL进行编码，使其成为有效的URI请求。

在实践中，以下是使用上述方法处理常见输入字段的几个示例。

（1）姓氏字段。这是一个很好的应用限制输入的示例。在这种情况下，可以接受的字符串范围为ASCII A-Z和a-z，以及连字符和波浪线（在SQL中，波浪线没有意义），以便处理类似O'Dell之类的姓氏。还应限制输入内容的最大长度。

（2）数量字段。这是应用输入限制的另一个例子。在此示例中，可以使用简单的类型和范围限制。例如，输入数据应该是介于0～1000之间的正整数。

（3）自定义文本字段。示例包括留言板上的备注字段。在这种情况下，您可能被允许输入字母和空格，以及省略符号、逗号和连字符等常用字符。允许输入的字符集只包括符号、括号和大括号。

有些应用程序可能允许用户使用一组有限的脚本字符修饰文本，如粗体“<b>”、斜体“<b>”，甚至包含指向他们所喜爱的URL的连接。处理URL时，验证时应先对所输入的值进行编码，以便将其作为URL处理。

（4）不验证用户输入的现有Web应用程序。在理想方案中，应用程序将检查每个字段和入口点的输入内容是否可以接受。然而，如果现有Web应用程序不验证用户输入，则需要一种权宜方法来降低风险，直到改进应用程序的输入验证策略。以下两种方法都不能确保输入数据的安全处理，因为这要依赖于输入的来源，以及应用程序使用输入数据的方式，目前，它们作为快速的补救措施，能在短期内提高应用程序的安全性。

① 向客户端写回数据时，对用户输入的数据进行HTML编码和URL编码。在这种情况下，假设所有输入均未作为HTML处理，并且向客户端写回的所有输出都包含在受保护的表单中。这是净化操作在起作用。

② 拒绝恶意脚本字符。这是一个拒绝已知有害输入的示例。在这种情况下，将使用可配置的恶意字符集来拒绝输入。如上所述，这种方法存在的问题是，有害数据是与上下文相关的。

毋庸置疑，SSL无法阻止攻击者向服务器提交专门设计的输入。应用程序使用SSL仅仅表示网络上的其他用户无法查看或修改攻击者传送的数据。因为攻击者控制着SSL通道的终端，能够通过这条通道向服务器传送任何内容。如果前面提到的任何攻击成功实现，那么不论其在FAQ中声称其如何安全，该应用程序都很容易受到攻击。

1.2.3 Web应用程序中存在的安全风险

任何情况下，如果一个应用程序必须接受并处理可能是恶意的未经验证的数据，就会产生Web应用程序面临的核心安全问题。但是，对Web应用程序而言，几种因素的结合使问题更加严重，这也解释了当今互联网上许多Web应用程序无法很好地解决这一问题的原因。

1．不成熟的安全意识

近年来，人们对Web应用程序安全问题的意识有所增强，但与网络和操作系统这些发展更加完善的领域相比，人们对Web应用程序安全问题的意识还远不够成熟。虽然大多数IT安全人员掌握了相当多的网络安全与主机强化基础知识，但他们对与Web应用程序安全有关的许多核心概念仍然不甚了解，甚至存有误解。当前，在其工作中，Web应用程序开发人员往往需要整合数十甚至数百个第三方数据包，导致他们无法集中精力研究基础技术。即使是经验丰富的Web应用程序开发人员，也经常会对所用的编程框架的安全性做出错误假设，或遇到一些对他们而言完全陌生的基本缺陷类型。

2．独立开发

大多数Web应用程序都由企业自己的员工或合作公司独立开发，即使应用程序采用第三方组件，通常也是使用新代码将第三方组件进行自定义或拼凑在一起。在这种情况下，每个应用程序都各不相同，并且可能包含其独有的缺陷。这种情形与组织购买业内一流产品并按照行业标准指南安装的典型基础架构部署形成鲜明对照。

3．欺骗性的简化

使用今天的Web应用程序和开发工具，一个程序员新手也能在短期内从头开始创建一个强大的应用程序。但是，在编写功能性代码与编写安全代码之间存在巨大的差异。许多Web应用程序由善意的个人创建，他们只是缺乏发现安全问题的知识与经验。

近年来出现了一种显著趋势，即使用提供现成代码组件的应用程序框架来处理各种常见的功能，这些功能包括身份验证、页面模板、公告牌及与常用后端基础架构组件的集成，等等。Liferay和Appfuse就属于这种类型的框架。使用这些产品可以快速、方便地创建可运行的应用程序，而无须了解这些应用程序的运行机制或它们包含的潜在风险。这也意味着许多公司会使用相同的框架。因此，即使仅仅出现一个漏洞，该漏洞也将会影响许多无关的应用程序。

4．迅速发展的威胁形势

Web应用程序攻击与防御研究发展相对不成熟，是一个正蓬勃发展的领域，其中新概念与威胁出现的速度比传统的技术要快得多。在客户端方面尤其如此，针对特定攻击的公认防御机制往往会在一些研究中失去作用，这些研究最终成就了新的攻击技巧。在项目开始之初就完全了解了当前威胁的开发团队，很可能到应用程序开发完成并部署后会面临许多未知的威胁。

5．资源与时间限制

由于独立、一次性开发的影响，许多Web应用程序开发项目会受到严格的时间与资源限制。通常，设计或开发团队不可能雇用专职的安全专家，而且由于项目进程的拖延，往往要等到项目周期的最后阶段才由专家进行安全测试。为了兼顾各种要素，按期开发出稳定而实用的应用程序的要求往往使开发团队忽视不明显的安全问题。小型组织一般不愿多花时间评估一个新的应用程序。快速渗透测试通常只能发现明显的安全漏洞，而往往会遗漏比较细微、需要时间和耐心来发现的漏洞。

6．技术上强其所难

Web应用程序使用的许多核心技术出现于万维网早期阶段，那时的状况与目前十分不同。从那以后，其功能已远远超越最初的设想，如在许多基于AJAX的应用程序中使用Java Script进行数据传输。随着对Web应用程序功能要求的变化，用于实现这种功能的技术已远远落后于其发展要求，而开发人员还是沿用原有的技术来满足新的需求。因此，这种做法造成的安全漏洞与无法预料的负面影响也就不足为奇了。

7．对功能的需求不断增强

在设计应用程序时，开发人员主要考虑的是功能和可用性。曾经静态的用户资源现在包含社交网络功能，允许用户上传照片，对页面进行“维基”风格的编辑。以前，应用程序设计人员可以仅仅通过用户名和密码来创建登录功能，而现今的站点则包含密码恢复、用户名恢复、密码提示，以及在将来访问时记住用户名和密码的选项。无疑，这类站点声称能够提供各种安全功能，但实际上，这些功能不过是增大了该站点的受攻击面而已。

8．Web应用程序体系结构设计不当

Web应用程序向设计人员和开发人员提出了许多挑战。HTTP是无国界的，这意味着跟踪每位用户的会话状态将成为应用程序的责任。作为先导者，应用程序必须能够通过某种形式的身份验证来识别用户。由于所有后续授权决策都要基于用户的标识，因此，身份验证过程必须是安全的，同样必须很好地保护用于跟踪已验证用户的会话处理机制。设计安全的身份验证和会话管理机制仅仅是Web应用程序设计人员和开发人员所面临的众多问题中的两个方面。由于输入和输出数据要在公共网络上进行传输，因此还会存在其他挑战。防止参数操作和敏感数据泄漏是另一些重要问题。

表1-1显示了由于设计不当导致的Web应用程序漏洞及潜在问题。

1.2.4 Web应用程序安全的预防及发展趋势

在Web应用程序出现之前，主要在网络边界上抵御外部攻击。保护这个边界需要对其提供的服务进行强化、打补丁，并在用户访问之间设置防火墙。Web应用程序改变了这一切。用户要访问应用程序，边界防火墙必须允许其通过HTTP/HTTPS连接内部服务器；应用程序要实现其功能，必须允许其连接服务器以支持后端系统，如数据库、大型主机及金融与后勤系统，这些系统通常处于组织运营的核心部分，并由几层网络级防御保护。

如果Web应用程序存在漏洞，那么公共互联网上的攻击者只需从Web浏览器提交专门设计的数据就可攻破组织的核心后端系统。这些数据会像传送至Web应用程序的正常、良性数据流一样，穿透组织的所有网络防御。

Web应用程序的广泛应用使得典型组织的安全边界发生了变化。部分安全边界仍旧关注防火墙与防御主机，但大部分安全边界更加关注组织所使用的Web应用程序。Web应用程序接收用户输入的方式多种多样，将这些数据传送至敏感后端系统的方式也多种多样，这些都是一系列攻击的潜在关口，因此必须在应用程序内部执行防御措施，以阻挡这些攻击。即使某个Web应用程序中的某一行代码存在缺陷，也会使组织的内部系统易于遭受攻击。此外，随着“聚合”应用程序、第三方小部件及其他跨域集成技术的出现，服务器端安全边界常常会跨越组织本身的边界。而且，各种组织还盲目地信任外部应用程序和服务。前述有关该新的安全边界内漏洞发生概率的统计数据值得每一个组织思考。

对一个针对组织的攻击者而言，获得网络访问权或在服务器上执行任意命令可能并不是他们真正想要实现的目标。大多数或者基本上所有攻击者的真实意图是执行一些应用程序级行为，如偷窃个人信息、转账或购买价格低廉的产品。而应用程序层面上存在的安全问题对实现这些目标有很大帮助。

Web应用程序安全边界发生变化的另一原因，在于用户本身在访问一个易受攻击的应用程序时面临的威胁。恶意攻击者可能会利用一个良性但易受攻击的Web应用程序攻击任何访问它的用户。如果用户位于企业内部网络，攻击者可能会控制用户的浏览器，并从用户的可信位置向本地网络发动攻击。如果攻击者心存恶意，他不需要用户的任何合作，就可以代表用户执行任何行为。随着浏览器扩展技术的兴起，各种插件不断增多，客户端受攻击面的范围也明显变大。

网络管理员清楚如何防止其用户访问恶意的Web站点，终端用户也逐渐意识到这种威胁。但是，鉴于Web应用程序漏洞的本质，与一个全然恶意的Web站点相比，易受攻击的应用程序至少给用户及其组织带来了一种威胁。因此，新的安全边界要求所有应用程序的所有者承担保护其用户的责任，使他们免受通过应用程序传送的攻击。

此外，人们普遍采用电子邮件作为一种补充验证机制，安全边界在一定程度上向客户端转移。当前，大量应用程序都包含“忘记密码”功能，攻击者可以利用该功能向任何注册地址发送账户恢复电子邮件，而无须任何其他用户特定的信息。因此，如果攻击者攻破了用户的Web邮件账户，就可以轻松扩大攻击范围，并攻破受害用户注册的大多数Web应用程序账户。

Web应用程序安全的预防措施有以下几种。

（1）确定安全Web应用程序的重要体系结构和设计问题。

（2）设计时考虑重要部署问题。

（3）制定能增强Web应用程序输入验证的策略。

（4）设计安全的身份验证和会话管理机制。

（5）选择适当的授权模型。

（6）实现有效的账户管理方法，并保护用户会话。

（7）对隐私、认可、防止篡改和身份验证信息进行加密。

（8）防止参数操作。

（9）设计审核和记录策略。

Web应用程序安全的发展趋势：虽然经过约10年的广泛应用，但目前互联网上的Web应用程序仍然充满漏洞。在了解Web应用程序面临的安全威胁及如何有效应对这些威胁方面，整个行业仍未形成成熟的意识。目前几乎没有迹象表明上述问题能够在不远的将来得到解决。

也就是说，Web应用程序的安全形势并非静止不变。尽管SQL注入等熟悉的传统漏洞还在不断出现，但已不是主要问题。而且，现有的漏洞也变得更难以发现和利用。几年前只需使用浏览器就能够轻易探测与利用的小漏洞，现在需要花费大量精力开发先进技术来发现。

Web应用程序安全的另一个突出趋势：攻击目标已由传统的服务器端应用程序转向用户应用程序。后一类攻击仍然需要利用应用程序本身的缺陷，但这类攻击一般要求与其他用户进行某种形式的交互，以达到破坏用户与易受攻击的应用程序之间交易的目的。其他软件安全领域也同样存在这种趋势。随着安全威胁意识的增强，服务器端存在的缺陷首先应为人们所理解并得到解决，从而可以在进一步的研究过程中将注意力集中在客户端。

Web应用程序安全预防方法中必须解决的其他重要问题如图1-6所示。

技术领域的各种最新趋势在一定程度上改变了Web应用程序的安全状态。一些极具误导性的热门词汇使这些趋势深入人心，下面是一些最热门的词汇。

（1）大数据。这一术语指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。

（2）云计算。这一术语指更多地通过外部服务提供商来实施技术栈的各个部分，包括应用程序软件、应用程序平台、Web服务器软件、数据库和硬件。它也指在托管环境中大量采用虚拟化技术。云计算是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。云是网络、互联网的一种比喻说法。过去在图中往往用云来表示电信网，后来也用云来表示互联网和底层基础设施的抽象。因此，云计算甚至可以让你体验每秒10万亿次的运算能力，拥有这么强大的计算能力可以模拟核爆炸、预测气候变化和市场发展趋势。用户通过计算机、笔记本电脑、手机等方式接入数据中心，按自己的需求进行运算。

（3）Web 6.0。这一术语指本质上不是单纯的互联网技术或衍生思想，而是物联网与互联网的初步结合，一种全新模式，惠及广大网民。这里不要将物联网看成是互联网的附庸，它是与互联网等价的物理媒介，是即将改变世界的新的物理模式。在Web 6.0里每个人都有调动自己感官的无限权力，用自己的五官去重新发现世界，从而改变世界。

和技术领域的大多数变革一样，这些趋势也催生了一些新型攻击，并导致现有攻击产生变体。虽然这些趋势受到人们的大肆追捧，但鉴于其导致的各种问题，它们并不像人们最初认为的那样会带来颠覆性的改变。我们将在本书的相应部分讨论与这些及其他最新趋势有关的安全问题。

尽管Web应用程序发生了这些改变，一些典型漏洞并未表现出任何减少的迹象。它们继续出现，方式与Web技术发展初期大致相同。这些漏洞包括业务逻辑缺陷、未能正确应用访问控制及其他设计问题。即使在应用程序组件紧密集成及“一切皆服务”的时代，这些问题仍然会广泛存在。