Web 应用的基础概念
在讨论 Web 应用安全之前，先简单介绍一下 Web 应用基础概念，这样便于理解为什么 Web 应用是脆弱的，容易受到攻击。
1、 什么是 Web 应用
Web 应用是由动态脚本、编译过的代码等组合而成。它通常架设在 Web 服务器上，用户在 Web 浏览器上发送请求，这些请求使用 HTTP 协议，经过因特网和企业的 Web 应用交互，由 Web 应用和企业后台的
数据库及其他动态内容通信。
2、 Web 应用的架构
尽管不同的企业会有不同的 Web 环境搭建方式，一个典型的 Web 应用通常是标准的三层架构模型，如图 1 所示。
图 1: Web 应用通常是标准的三层架构模型
Web
在这种最常见的模型中，客户端是第一层；使用动态 Web 内容技术的部分属于中间层；数据库是第三层。用户通过 Web 浏览器发送请求（request）给中间层，由中间层将用户的请求转换为对后台数据的查询或是更新，并将最终的结果在浏览器上展示给用户。
Web 应用安全全景
当讨论起 Web 应用安全，我们经常会听到这样的回答：
“我们使用了防火墙”、“我们使用了网络脆弱扫描工具”、“我们使用了 SSL 技术”、“我们每个季度都会进行渗透
测试”……所以，“我们的应用是安全的”。现实真是如此吗？让我们一起来看一下 Web 应用安全的全景图。
图 2: 信息安全全景
信息安全全景
在企业 Web 应用的各个层面，都会使用不同的技术来确保安全性。为了保护客户端机器的安全，用户会安装防病毒软件；为了保证用户数据传输到企业 Web 服务器的传输安全，通信层通常会使用 SSL（安全套接层）技术加密数据；企业会使用防火墙和 IDS（入侵诊断系统）/IPS（入侵防御系统）来保证仅允许特定的访问，不必要暴露的端口和非法的访问，在这里都会被阻止；即使有防火墙，企业依然会使用身份认证机制授权用户访问 Web 应用。
但是，即便有防病毒保护、防火墙和 IDS/IPS，企业仍然不得不允许一部分的通讯经过防火墙，毕竟 Web 应用的目的是为用户提供服务，保护措施可以关闭不必要暴露的端口，但是 Web 应用必须的 80 和 443 端口，是一定要开放的。可以顺利通过的这部分通讯，可能是善意的，也可能是恶意的，很难辨别。这里需要注意的是，Web 应用是由软件构成的，那么，它一定会包含缺陷（bugs），这些 bug 就可以被恶意的用户利用，他们通过执行各种恶意的操作，或者偷窃、或者操控、或者破坏 Web 应用中的重要信息。
因此可以看出，企业的回答，并不能真正保证企业的应用安全：
网络脆弱性扫描工具，由于它仅仅用来分析网络层面的漏洞，不了解应用本身，所以不能彻底提高 Web 应用安全性；
防火墙可以阻止对重要端口的访问，但是 80 和 443 端口始终要开放，我们无法判断这两个端口中通讯数据是善意的访问还是恶意的攻击；
SSL 可以加密数据，但是它仅仅保护了在传输过程中数据的安全性，并没有保护 Web 应用本身；
每个季度的渗透测试，无法满足处于不断变更之中的应用。
只要访问可以顺利通过企业的防火墙，Web 应用就毫无保留的呈现在用户面前。只有加强 Web 应用自身的安全，才是真正的 Web 应用安全解决之道。
常见的 Web 应用攻击
两个重要的国际应用安全组织
在讨论常见的 Web 应用攻击之前，我们需要先了解两个组织：WASC 和 OWASP。这两个组织在呼吁企业加强应用安全意识和指导企业开发安全的 Web 应用方面，起到了重要的作用。
Web Application Security Consortium（WASC），是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体。他们负责为 WWW 制定被广为接受的应用安全标准。WASC 组织的关键项目之一是“Web 安全威胁分类”，也就是将 Web 应用所受到的威胁、攻击进行说明并归纳成具有共同特征的分类。该项目的目的是针对 Web 应用的安全隐患，制定和推广行业标准术语。WASC 将 Web 应用安全威胁分为如下六类：
Authentication（验证）
用来确认某用户、服务或是应用身份的攻击手段。
Authorization（授权）
用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段。
Client-Side Attacks（客户侧攻击）
用来扰乱或是探测 Web 站点用户的攻击手段。
Command Execution（命令执行）
在 Web 站点上执行远程命令的攻击手段。
Information Disclosure（信息暴露）
用来获取 Web 站点具体系统信息的攻击手段。
Logical Attacks（逻辑性攻击）
用来扰乱或是探测 Web 应用逻辑流程的攻击手段。
可以通过如下的网址访问该组织网站，获得更多详细信息：[url]www.webappsec.org[/url]。也可以通过参考资料中链接，具体了解“Web 安全威胁分类”项目。
Open Web Application Security Project（OWASP），该组织致力于发现和解决不安全 Web 应用的根本原因。它们最重要的项目之一是“Web 应用的十大安全隐患”，总结了目前 Web 应用最常受到的十种攻击手段，并且按照攻击发生的概率进行了排序。这个项目的目的是统一业界最关键的 Web 应用安全隐患，并且加强企业对 Web 应用安全的意识。
图 3: Web 应用十大安全隐患
Web
可以通过如下的网址访问该组织。
IBM Rational，是上述两个组织的成员。
常见的 Web 应用攻击示例
在 OWASP 组织列举的十大 Web 应用安全隐患中，有两个概率最高的攻击手段，它们分别是“跨站点脚本攻击”（Cross-Site Scripting）和“注入缺陷”（Injection Flaws）。下面将通过举例来说明这两种攻击是如何实施的。
1、 跨站点脚本攻击
首先来看一下跨站点脚本的利用过程，如图 4。
图 4: 跨站点脚本攻击的过程
跨站点脚本攻击的过程
在上图中，恶意攻击者（这里使用 Evil.org 表示）通过 E-mail 或 HTTP 将某银行的网址链接发给用户（银行用 bank.com 表示），该链接中附加了恶意的脚本（上图步骤一）；用户访问发来的链接，进入银行网站，同时，嵌在链接中的脚本被用户的浏览器执行（上图步骤二、三）；用户在银行网站的所有操作，包括用户的 cookie 和 session 信息，都被脚本收集到，并且在用户毫不知情的情况下发送给恶意攻击者（上图步骤四）；恶意攻击者使用偷来的 session 信息，伪装成该用户，进入银行网站，进行非法活动（上图步骤五）。
因此，只要 Web 应用中，有可被恶意攻击者利用执行脚本的地方，都存在极大的安全隐患。黑客们如果可以让用户执行他们提供的脚本，就可以从用户正在浏览的域中偷到他的个人信息、可以完全修改用户看到的页面内容、跟踪用户在浏览器中的每一个动作，甚至利用用户浏览器的缺陷完全控制用户的机器。
目前，跨站点脚本攻击是最大的安全风险。
2、 注入缺陷
目前的 Web 应用中，绝大多数都会向用户提供一个接口，用来进行权限验证、搜索、查询信息等功能。比如一个在线银行应用，首先会有对注册客户进行身份验证的登录界面，在正确登录后，会提供更多交互功能，如根据客户的银行卡号信息，查询客户的最近交易、转账细节等。这些都是注入缺陷的最佳利用场景。所谓注入缺陷，就是在上述场景中，用户输入的数据被当做命令和查询的一部分，送到后端的解释器中解释执行。如果用户的输入是正常合法的，Web 应用自然会返回正常合理的结果，但是，如果恶意攻击者，利用输入数据可被后台执行的原理，偷梁换柱，使用非法的输入，脆弱的 Web 应用会怎样呢？
下面我们举一个例子来说明注入缺陷是如何进行的。在一个交易网站中，用户必须输入产品 ID 号才可以查看该产品的详细信息。为了实现这个需求，通常会用 SQL 语句查询数据库来实现。开发人员在编写应用程序时，可能会使用如下的 SQL 语句来实现上述目的（这里仅为示例）：
1) Select * from products where product_id = ` + 用户输入的 ID + `
这里的 products 是数据库中用来存放产品信息的表，＋号表示 SQL 语句需要和用户输入的真实 ID 进行拼接。如果用户输入 325，则该语句在执行时变为：
Select * from products where product_id = ` 325 `
数据库会将 ID 为 325 的产品信息返回给用户。
2) 在界面上，需要用户输入产品 ID 的地方，黑客会输入如下数据：
` or `1`= `1
可以看到，黑客并没有输入正常合法的产品编号。
3) 通过黑客的非法输入，需要执行的 SQL 语句变为：
Select * from products where product_id = ` ` or `1`=`1`
可以看出，SQL 语句的意义就完全改变了，当产品 ID 为空或者 1＝1 时，返回产品所有信息，而 1＝1 是永远成立的条件，因此，黑客并没有输入任何产品编号，就可以返回数据库中所有产品的详细信息。
通过这个例子，我们可以看出，注入缺陷是风险非常高的安全漏洞，一旦 Web 应用中给用户提供了需要其输入数据的接口，就有可能遭到攻击，将后台的数据完全暴露在用户的面前。
上述说明的“跨站点脚本攻击”和“注入缺陷攻击”，是目前 Web 应用中比例最高的两种攻击手段，按照 OWASP 的项目排序，还有如下八种风险性较高的攻击方法：
Malicious File Execution（恶意文件执行）；
Insecure Direct Object Reference（不安全的直接对象引用）；
Cross-Site Request Forgery（跨站点的请求伪造）；
Information Leakage and Improper Error Handling（信息泄漏和不正确的错误处理）；
Broken Authentication & Session Management（损坏的认证和 Session 管理）；
Insecure Cryptographic Storage（不安全的密码存储）；
Insecure Communications（不安全的通信）；
Failure to Restrict URL Access（未能限制 URL 访问）
在这里，我们就不过多的讨论这几种安全隐患，可以使用 3.1 节中提供的链接得到更多的描述信息。
构筑安全的 Web 应用
功能和性能，往往是我们衡量应用是否满足需求的指标，但是，对于载体为 Internet 的特殊应用－Web 应用而言，安全性也是必要的考量标准，皮之不存，毛将焉附？如果失去了安全性，即使功能再完备、性能再可靠的 Web 应用，一旦遭到黑客的攻击和破坏，一切都失去了意义。因此企业，尤其是提供 Web 应用的企业，一定要加强对应用安全的重视程度。
针对目前 Web 应用安全性不高的现状，IBM Rational 提出了构筑安全 Web 应用的解决方案。
加强全员应用安全性意识
一个根本、底层的战略手段就是加强企业全员的应用安全意识。正如前面所阐述过的，对于应用而言，无论是开发人员、测试人员、质量管理人员还是项目经理、企业高层，都会对其功能和性能做更多的关注，这也是由于早期应用多为 C/S 架构的应用，安全问题并不突出。但是在当今的环境，就不得不将安全作为应用质量的基础。
图 5 中功能、易用性、可靠性、性能、可支持性，是由 Rational Unified Process（RUP）定义的 FURPS 质量模型，它告诉我们应用的质量需要从这几个方面着手衡量，对于 Web 应用，就必须将安全性作为质量模型的基础条件。
图 5: 适于 Web 应用的质量模型