为什么80%的码农都做不了架构师？>>>   

反射型XSS漏洞 如果一个应用程序使用动态页面向用户显示错误消息，就会造成一种常见的XSS漏洞。通常，该页面会使用一个包含消息文本的参数，并在响应中将这个文 本返回给用户。对于开发者而言，使用这种机制非常方便，因为它允许他们从应用程序中调用一个定制的错误页面，而不需要对错误页面中的消息分别进行硬编码。 例如，下面的URL返回如图12-1所示的错误消息：
https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred 分析被返回页面的HTML源代码后，我们发现，应用程序只是简单复制URL中message参数的值，并将这个值插入到位于适当位置的错误页面模板中：

1. <p>Sorry, an error occurred.</p>

提取用户提交的输入并将其插入到服务器响应的HTML代码中，这是XSS漏洞的一个明显特征；如果应用程序没有实施任何过滤或净化措施，那么它很容易受到攻击。让我们来看看如何实施攻击。 下面的URL经过专门设计，它用一段生成弹出对话框的JavaScript代码代替错误消息：

1. https://wahh-app.com/error.php?message=<script>alert(”xss”）;</script>

请求这个URL将会生成一个HTML页面，其中包含以下替代原始消息的脚本：

1. <p><script>alert(”xss”）;</script></p>

可以肯定，如果该页面在用户的浏览器中显示，弹出消息就会出现，如图12-2所示。

一次概念验证XSS攻击

进行这个简单的测试有助于澄清两个重要问题：首先，message参数的内容可用任何返回给浏览器的数据替代；其次，无论服务器端应用程序如何处理这些数据（如果有），都无法阻止提交JavaScript代码，一旦错误页面在浏览器中显示，这些代码就会执行。 在现实世界的Web应用程序中存在的XSS漏洞，有近75%的漏洞属于这种简单的XSS bug。由于利用这种漏洞需要设计一个包含嵌入式JavaScript代码的请求，随后这些代码又被反射到任何提出请求的用户，因而它被称作反射型 XSS。攻击有效载荷分别通过一个单独的请求与响应进行传送和执行。为此，有时它也被称为一阶XSS。
利用漏洞 下文将会介绍，利用XSS漏洞攻击应用程序其他用户的方式有很多种。最简单的一种攻击，也是我们常用于说明XSS漏洞潜在影响的一种攻击，可导致攻击者截获一名通过验证的用户的会话。劫持用户的会话后，攻击者就可以访问该用户经授权访问的所有数据和功能。 实施这种攻击的步骤如图12-3所示。  

反射型XSS攻击的实施步骤

(1) 用户正常登录应用程序，得到一个包含会话令牌的 cookie：  

(2) 攻击者通过某种方法（详情见下文）向用户提交以下 URL：  

和前面生成一个对话框消息的示例一样，这个URL包含嵌入式 JavaScript 代码。但是，这个示例中的攻击有效载荷更加恶毒。 (3) 用户从应用程序中请求攻击者传送给他们的URL。 (4) 服务器响应用户的请求。由于应用程序中存在XSS漏洞，响应中包含攻击者创建的 JavaScript代码。 (5) 用户浏览器收到攻击者的JavaScript代码，像执行从应用程序收到的其他代码一样，浏览器执行这段代码。 (6) 攻击者创建的恶意JavaScript代码为：  

这段代码可让用户浏览器向wahh-attacker.com（攻击者拥有的一个域）提出一个请求。请求中包含用户访问应用程序的当前会话令牌：  

攻击者监控访问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攻击。

转载于:https://my.oschina.net/766/blog/211525