参考链接：http://book.51cto.com/art/200907/138792.htm
一、 反射型XSS漏洞
如果一个应用程序使用动态页面向用户显示错误消息，就会造成一种常见的XSS漏洞。通常，该页面会使用一个包含消息文本的参数，并在响应中将这个文本返回给用户。对于开发者而言，使用这种机制非常方便，因为它允许他们从应用程序中调用一个定制的错误页面，而不需要对错误页面中的消息分别进行硬编码。
例如，下面的URL返回如图12-1所示的错误消息：
https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred
分析被返回页面的HTML源代码后，我们发现，应用程序只是简单复制URL中message参数的值，并将这个值插入到位于适当位置的错误页面模板中：
 |
| （点击查看大图）图12-1 一条动态生成的错误消息 |
- <p>Sorry, an error occurred.</p>
提取用户提交的输入并将其插入到服务器响应的HTML代码中，这是XSS漏洞的一个明显特征；如果应用程序没有实施任何过滤或净化措施，那么它很容易受到攻击。让我们来看看如何实施攻击。
下面的URL经过专门设计，它用一段生成弹出对话框的JavaScript代码代替错误消息：
- https://wahh-app.com/error.php?message=<script>alert('xss'）;</script>
请求这个URL将会生成一个HTML页面，其中包含以下替代原始消息的脚本：
可以肯定，如果该页面在用户的浏览器中显示，弹出消息就会出现，如图12-2所示。
- <p><script>alert('xss'）;</script></p>
 |
| （点击查看大图）图12-2 一次概念验证XSS攻击 |
进行这个简单的测试有助于澄清两个重要问题：首先，message参数的内容可用任何返回给浏览器的数据替代；其次，无论服务器端应用程序如何处理这些数据（如果有），都无法阻止提交JavaScript代码，一旦错误页面在浏览器中显示，这些代码就会执行。
在现实世界的Web应用程序中存在的XSS漏洞，有近75%的漏洞属于这种简单的XSS bug。由于利用这种漏洞需要设计一个包含嵌入式JavaScript代码的请求，随后这些代码又被反射到任何提出请求的用户，因而它被称作反射型XSS。攻击有效载荷分别通过一个单独的请求与响应进行传送和执行。为此，有时它也被称为一阶XSS。
利用漏洞
下文将会介绍，利用XSS漏洞攻击应用程序其他用户的方式有很多种。最简单的一种攻击，也是我们常用于说明XSS漏洞潜在影响的一种攻击，可导致攻击者截获一名通过验证的用户的会话。劫持用户的会话后，攻击者就可以访问该用户经授权访问的所有数据和功能。
实施这种攻击的步骤如图12-3所示。
 |
| （点击查看大图）图12-3 反射型XSS攻击的实施步骤 |
(1) 用户正常登录应用程序，得到一个包含会话令牌的 cookie：
 |
(2) 攻击者通过某种方法（详情见下文）向用户提交以下 URL：
 |
和前面生成一个对话框消息的示例一样，这个URL包含嵌入式 JavaScript 代码。但是，这个示例中的攻击有效载荷更加恶毒。
(3) 用户从应用程序中请求攻击者传送给他们的URL。
(4) 服务器响应用户的请求。由于应用程序中存在XSS漏洞，响应中包含攻击者创建的 JavaScript代码。
(5) 用户浏览器收到攻击者的JavaScript代码，像执行从应用程序收到的其他代码一样，浏览器执行这段代码。
(6) 攻击者创建的恶意JavaScript代码为：
 |
 |
攻击者监控访问wahh-attacker.com的请求并收到用户的请求。攻击者使用截获的令牌劫持用户的会话，从而访问该用户的个人信息，并"代表"该用户执行任意操作。
注解 第6章已经介绍过，一些应用程序保存一个持久性cookie，以在用户每次访问时重新对其进行有效验证，例如，执行"记住我"功能。这时，就没有必要执行上述过程中的第一个步骤。即使目标用户并未处于活动状态或登录应用程序，攻击者仍然能够成功实现目标。为此，以这种方式使用cookie的应用程序更易受到XSS漏洞的影响。
完成上述步骤后，读者可能会心存疑惑：如果攻击者能够诱使用户访问他选择的URL，那么他为什么还要费这么大力气通过应用程序中的XSS漏洞传送自己的恶意JavaScript代码呢？为什么他不在wahh-attacker.com上保存一段恶意脚本，并向用户传送一个直接指向这段脚本的链接呢？这段脚本不是可以和上例中的脚本一样执行吗？
实际上，攻击者之所以利用XSS漏洞，有两个重要的原因。第一个也是最重要的原因在于，攻击者的目的并不仅仅是执行任意一段脚本，而是截获用户的会话令牌。浏览器不允许任何旧有脚本访问一个站点的cookie，否则，会话就很容易被劫持。而且，只有发布cookie的站点能够访问这些cookie：仅在返回发布站点的HTTP请求中提交cookie；只有通过该站点返回的页面所包含或加载的JavaScript才能访问cookie。因此，如果wahh-attacker.com上的一段脚本查询 document. cookie，它将无法获得wahh-app.com发布的cookie，劫持攻击也不会成功。
就用户的浏览器而言，利用XSS漏洞的攻击之所以取得成功，是因为攻击者的恶意JavaScript是由wahh-app.com送交给它的。当用户请求攻击者的URL时，浏览器向https://wahh-app.com/error.php提交一个请求，然后应用程序返回一个包含一段JavaScript的页面。和从wahh-app.com收到的任何JavaScript一样，浏览器执行这段脚本，因为用户信任wahh-app.com。这也就是为何攻击的脚本能够访问wahh-app.com发布的cookie的原因，虽然它实际来自其他地方。这也是为何该漏洞被称作跨站点脚本的原因。
注解 对脚本能够访问的数据实施这种限制，是所有现代浏览器所执行的更加通用的同源策略的一部分。实施这个策略是为了在浏览器访问的不同Web站点之间设立障碍，防止它们相互干扰。关于这个策略，必须了解以下一些主要特点。
一个域的页面可向另一个域提出任意请求（例如，通过提交一个表单或加载一幅图像），但它不能处理那个请求返回的数据。
一个域的页面可从另一个域加载一段脚本，并在自己的域内执行这段脚本。这是因为脚本被假定包含代码而非数据，因此跨域访问并不会泄露任何敏感信息。如上所述，在某些情况下，这种假设被违反了，从而导致跨域攻击。
一个域的页面不能读取或修改属于另一个域的cookie或其他DOM数据（如上例所述）。
攻击者利用XSS漏洞的第二个原因在于，如果攻击者设计的URL以wahh-app.com而不是wahh-attacker.com开头，上面的第二个步骤就更有可能成功。假设攻击者送出数百万封下面这样的电子邮件，试图欺骗受害者：
 |
即使对钓鱼攻击有所防范的用户而言，这种电子邮件也相当可靠。
邮件要求他们用自己常用的书签访问账户。
邮件要求他们单击的链接指向应用程序使用的正确域名。
与上面第二步的URL不同，邮件中的URL经过模糊处理；它对URL中的一些字符进行了 URL编码，以使恶意目的不是非常明显。
该邮件可通过HTTPS安全检查，因为攻击者提供的URL确实是由wahh-app.com服务器传送的。
如果攻击者不利用XSS漏洞，而是提供一个指向自己恶意Web服务器的链接，执行纯粹的钓鱼攻击，许多不易受骗的用户就会怀疑这是一个陷阱，攻击的成功率也因此降低。
错误观点 "钓鱼陷阱是因特网上无法回避的事实，我对它们无能为力。尝试修复我的应用程序中的XSS漏洞完全是浪费时间。
钓鱼攻击与XSS漏洞完全不同。纯粹的钓鱼陷阱是指克隆一个目标应用程序，并通过某种方法诱使用户与其交互。另一方面，XSS攻击可完全经由易受攻击的目标应用程序传送。许多人混淆XSS与钓鱼攻击，是因为有时它们使用的传送方法非常相似。但是，以下几个要点表明，与钓鱼攻击相比，XSS攻击会给组织带来更大的风险。
由于XSS攻击在用户当前使用的应用程序中执行，用户将会看到与其有关的个性化信息，如账户信息或"欢迎回来"消息。克隆的Web站点不会显示个性化信息。
通常，在钓鱼攻击中使用的克隆Web站点一经发现，就会立即被关闭。
许多浏览器与反恶意软件产品内置有一个钓鱼攻击过滤器，可阻止用户访问恶意的克隆站点。
如果客户访问一个克隆的Web站点，许多银行并不承担责任。但是，如果攻击者通过银行应用程序中的XSS漏洞攻击银行客户，他们就不能简单地推卸责任。
如下文所述，有许多方法可以传送不使用钓鱼攻击技巧的XSS攻击。
二、保存型XSS漏洞
另一种常见的XSS漏洞叫做保存型跨站点脚本。如果一名用户提交的数据被保存在应用程序中（通常保存在一个后端数据库中），然后不经适当过滤或净化就显示给其他用户，此时就会出现这种漏洞。
在支持终端用户交互的应用程序中，或者在具有管理权限的员工访问同一个应用程序中的用户记录和数据的应用程序中，保存型XSS漏洞很常见。例如，以一个拍卖应用程序为例，它允许买家提出与某件商品有关的问题，然后由卖家回答。如果一名用户能够提出一个包含嵌入式 JavaScript的问题，而且应用程序并不过滤或净化这个JavaScript，那么攻击者就可以提出一个专门设计的问题，在任何查看该问题的用户（包括卖家和潜在的买家）的浏览器中执行任意脚本。在这种情况下，攻击者就可让不知情的用户去竞标一件他不想要的商品；或者让一位卖家接受他提出的低价，结束竞标。
一般情况下，利用保存型XSS漏洞的攻击至少需要向应用程序提出两个请求。攻击者在第一个请求中传送一些专门设计的数据，其中包含恶意代码；应用程序接受并保存这些数据。在第二个请求中，一名受害者查看某个包含攻击者的数据的页面，这时恶意代码开始执行。为此，这种漏洞有时也叫做二阶跨站点脚本。（在这个示例中，使用XSS实际上并不准确，因为攻击中没有跨站点元素。但由于这个名称被人们广泛使用，因此我们在这里仍然沿用它。）
图12-4说明了一名攻击者如何利用保存型XSS漏洞，实施上述利用反射型XSS漏洞实施的相同会话劫持攻击。
反射型与保存型XSS攻击在实施步骤上存在两个重要的区别，这也使得后者往往造成更大的安全威胁。
首先，在反射型XSS脚本攻击中，要利用一个漏洞，攻击者必须以某种方式诱使受害者访问他专门设计的URL。而保存型XSS脚本攻击则没有这种要求。在应用程序中展开攻击后，攻击者只需要等待受害者浏览已被攻破的页面或功能。通常，这个页面是一个正常用户将会主动访问的常规页面。
其次，如果受害者在遭受攻击时正在使用应用程序，攻击者就更容易实现其利用XSS漏洞的目的。例如，如果用户当前正在进行会话，那么攻击者就可以劫持这个会话。在反射型XSS攻击中，攻击者可能会说服用户登录，然后单击他们提供的一个链接，从而制造这种情况。或者他可能会部署一个永久性的有效载荷并等待用户登录。但是，在保存型XSS攻击中，攻击者能够保证，受害用户在他实施攻击时已经在访问应用程序。因为攻击有效载荷被保存在用户自主访问的一个应用程序页面中，所以，当有效载荷执行时，任何攻击受害者都在使用应用程序。而且，如果上述页面位于应用程序通过验证的区域内，那么那时攻击受害者一定已经登录。
 |
| （点击查看大图）图12-4 保存型XSS漏洞的实施步骤 |
反射型与保存型XSS攻击之间的这些区别意味着保存型XSS漏洞往往会给应用程序带来更严重的安全威胁。许多时候，攻击者可以向应用程序提交一些专门设计的数据，然后等待受害者访问它们。如果其中一名受害者是管理员，那么攻击者就能够完全攻破整个应用程序。
在上传文件中保存XSS
如果应用程序允许用户上传可被其他用户下载并查看的文件，就会出现保存型XSS漏洞；然而，这种漏洞常常被人们忽略。如果能够上传一个包含JavaScript的HTML或文本文件，且受害者查看这份文件，那么有效载荷就可得到执行。
为防止这种攻击，许多应用程序禁止上传HTML文件；但是，大多数情况下，它们允许上传包含JPEG图像的文件。在Internet Explorer中，如果一名用户直接请求一个JPEG文件（并非通过嵌入式<img>标签），那么浏览器将会把它的内容当作HTML处理，就好像这是文件所包含的内容一样。这种行为意味着攻击者可以上传一个包含XSS有效载荷、以.jpg为扩展名的文件。如果应用程序并不核实文件是否确实包含一幅有效图像，并允许其他用户下载该文件，那么它就易于受到攻击。
下面是一个易于受到这种保存型XSS攻击的应用程序发出的原始响应。注意，即使Content-Type消息头规定消息主体中必须包含一幅图像，Internet Explorer会忽略这一要求并把内容当作HTML处理，因为文件实际包含的是HTML内容。
 |
三、基于DOM的XSS漏洞
反射型和保存型XSS漏洞都表现出一种特殊的行为模式，其中应用程序提取用户控制的数据并以危险的方式将这些数据返回给用户。第三类XSS漏洞并不具有这种特点。在这种漏洞中，攻击者的JavaScript通过以下过程得以执行。
用户请求一个经过专门设计的URL，它由攻击者提交，且其中包含嵌入式JavaScript。
服务器的响应中并不以任何形式包含攻击者的脚本。
当用户的浏览器处理这个响应时，上述脚本得以处理。
这一系列事件如何发生呢？由于客户端JavaScript可以访问浏览器的文本对象模型（Document Object Model，DOM），因此它能够决定用于加载当前页面的 URL。由应用程序发布的一段脚本可以从URL中提取数据，对这些数据进行处理，然后用它动态更新页面的内容。如果这样，应用程序就可能易于受到基于DOM的XSS攻击。
回到前面的反射型XSS漏洞中的示例，其中服务器端应用程序将一个URL参数值复制到一条错误消息中。另一种实现相同功能的办法是由应用程序每次返回相同的静态 HTML，并使用客户端JavaScript动态生成消息内容。
例如，假设应用程序返回的错误页面包含以下脚本：
 |
- https://wahh-app.com/error.php?message=<script>alert('xss'）;</script>
利用基于DOM的XSS漏洞的过程如图12-5所示。
 |
| （点击查看大图）图12-5 基于DOM的XSS攻击的实施步骤 |
1235
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
