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 应用的质量模型
