在 OWASP 组织列举的十大 Web 应用安全隐患中，有两个概率最高的攻击手段，它们分别是“跨站点脚本攻击”（Cross-Site Scripting）和“注入缺陷”（Injection Flaws）。下面将通过举例来说明这两种攻击是如何实施的。
1、 跨站点脚本攻击
首先来看一下跨站点脚本的利用过程，如图 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 访问）