跨站点脚本攻击（XSS）深入解析
在跨站脚本攻击中会发生什么
跨站脚本攻击（cross-site scripting，简称 XSS），是黑客用来潜入 Web 应用程序的最普遍的应用程序层攻击之一。XSS 是针对特殊 Web 站点的客户隐私的攻击，当客户详细信息失窃或受控时可能引发彻底的安全威胁。大部分网站攻击只涉及两个群体：黑客和 Web 站点，或者黑客和客户端受害者。与那些攻击不同的是，XSS 攻击同时涉及三个群体：黑客、客户端和 Web 站点。
XSS 攻击的目的是盗走客户端 cookies，或者任何可以用于在 Web 站点确定客户身份的其他敏感信息。手边有了合法用户的标记，黑客可以继续扮演用户与站点交互，从而冒充用户。举例来说，在对一个大型公司的调查中表明，利用 XSS 攻击窥视用户的信用卡号码和私有信息是可能的。这是通过利用 Web 站点的访问特权，在受害者（客户端）浏览器上运行恶意的 JavaScript 代码来实现的。这些是非常有限的 JavaScript 特权，除了与站点相关的信息，一般不允许脚本访问其他任何内容。重点强调的是，虽然 Web 站点上存在安全漏洞，但是 Web 站点从未受到直接伤害。但是这已经足够让脚本收集 cookies，并且将它们发送给黑客。因此，黑客获得 cookies 并冒充受害者。
XSS 技术的深入解析
让我们调用受攻击的站点： www.vulnerable.site。传统的 XSS 攻击的核心处位于脆弱的站点中的脆弱的脚本。这些脚本读取部分 HTTP 请求（通常是参数，但有时也有 HTTP 头域或路径），并且在首次不加密的情况下全部或部分地将其回送给响应页面（因而，不确保它不包含 JavaScript 代码或 HTML 标签）。因此，假设该脚本名为 welcome.cgi，其参数为 name。可以通过以下方式进行操作：
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site
响应是：
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker <BR>
Welcome to our system
...
</HTML>
这是怎样被盗用的呢？黑客设法引诱受害客户点击他们提供给用户的链接。这是一个精心设计且蓄含恶意的链接，诱使受害者的 Web 浏览器访问站点（ www.vulnerable.site），并调用入侵脚本。该脚本的数据里包含了用于非法访问客户端浏览器为 www.vulnerable.site 站点所存储 cookies 的 JavaScript。这是允许的，因为客户端浏览器“运行过”来自 www.vulnerable.site 的 JavaScript，并且 JavaScript 安全模型允许来自特殊站点的脚本访问属于该站点的 cookies。
这样的链接如下：
www.vulnerable.site 的请求，如下所示：
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
Host: www.vulnerable.site ...
脆弱的站点的响应是：
<HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script>
<BR> Welcome to our system ...
</HTML>
受害者客户端的浏览器将把该响应解释为包含一段 JavaScript 代码的 HTML 页面。当执行时，该代码被允许访问所有属于 www.vulnerable.site 的 cookies。因此，它将在客户端浏览器中弹出一个窗口，显示属于 www.vulnerable.site 的所有客户端 cookies。
当然，真正的恶意攻击包含了将这些 cookies 发送给黑客的操作。对此，黑客可能建立 Web 站点（ www.attacker.site）并使用脚本来接收 cookies。替代弹出窗口，黑客会书写访问 www.attacker.site 的 URL 的代码，从而调用接收 cookie 的脚本，其参数设置为被窃取的 cookies。这样，黑客可以从 www.attacker.site 服务器上获得 cookies。
恶意的链接会是：
>">
...
执行传统的 XSS 攻击的其他方式
到此为止，我们已经看到 XSS 攻击可以出现在用脚本回送响应的 GET 请求的参数中。但是也可以用 POST 请求实现攻击，或者利用 HTTP 请求的路径组件 ―― 甚至使用一些 HTTP 头（例如 Referer）。
特别是，当错误页面返回错误的路径时，路径组件就有用了。在这种情况下，包含在该路径中的恶意脚本经常都会执行。已发现许多 Web 服务器都容易受到这种攻击。
什么出了问题？
很重要的是要知道，虽然 Web 站点不直接受到这种攻击的影响（站点继续正常工作，恶意代码不在站点上执行，不会出现 DoS 情况，并且数据不直接受控，或从站点上读取），但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志（security token）部署应用程序，借此，黑客可以猜出客户的安全标志并冒充客户。
应用程序中的脆弱点是不管参数值是什么都回送参数的脚本。好的脚本确保参数的格式是适当的，包含合理的字符，等等。有效的参数通常没有合理的理由包含 HTML 标签或 JavaScript 代码，可靠起见，应该在这些内容嵌入响应之前，或者在应用程序中处理这些内容之前，将它们从参数中去掉。
如何保护站点不受 XSS 攻击
用这三种方式可以保护站点不受 XSS 攻击：
1. 执行内部的输入过滤（有时候称为输入清洁设备）。对于内部书写的每个脚本中的每个用户输入 ―― 参数或 HTTP 头，都应该应用高级的 HTML 标签（包括 JavaScript 代码）过滤。举例来说，来自之前的案例研究中的 welcome.cgi 脚本在解码 name 参数之后，应该过滤 <script> 标签。该方法有一些严重的不利因素：
o 它要求应用程序的编程人员非常精通安全。
o 它要求编程人员覆盖所有可能的输入来源（查询参数、POST 请求的 body 参数、HTTP 头）。
o 它不能抵御第三方脚本或服务器中的安全漏洞。举例来说，它不能防御 Web 服务器错误页面中的问题（通常显示了资源的路径）。
2. 执行“输出过滤”，换句话说，当发回给浏览器时过滤用户数据，而不是当被脚本接收时。一个很好的示例是通过一个脚本将输入数据插入到数据库中，然后再从数据库呈现数据。在这种情况下，重要的是不向原始的输入字符串应用过滤，而只向输出版本应用过滤。这种方法的缺陷类似于对输入过滤的缺陷。
3. 通过安装第三方应用程序防火墙，防火墙在 XSS 攻击到达 Web 服务器和易受攻击的脚本之前拦截它们，并阻塞它们。不论是来自内部应用程序的脚本或路径、第三方脚本，或根本不描述资源的脚本（举例来说，用来引起来自服务器的 404 页面响应的脚本），应用程序防火墙都可以以一般的方式覆盖所有输入方法（包括路径和 HTTP 头）。对于每个输入源，应用程序防火墙根据各种 HTML 标签模式和 JavaScript 模式检查数据。如果匹配成功，就拒绝该请求，恶意的输入不会到达服务器。
检查您的站点是否处于 XSS 攻击保护的方法
检查站点免于遭受 XSS 攻击是加强站点安全保护的必然结论。正如保护站点免于遭受 XSS 攻击一样，检查站点的确安全也可以通过手工完成（硬方法），或利用自动的 Web 应用程序安全漏洞评估工具，它减轻了检查的负担。该工具爬遍站点，然后根据尝试参数、头，和路径找到的所有脚本，运行其知道的所有变化。在这两种方法中，用尽可能多的方式检查对应用程序的每个输入（所有脚本的参数、HTTP 头、路径）。如果响应页面包含浏览器可以执行的 JavaScript 代码，那么 XSS 安全漏洞就已显露出来。举例来说，发送此文本：
<script>alert(document.cookie)</script>
对每个脚本的每个参数（通过允许 JavaScript 的浏览器暴露出最简单类型的 XSS 安全漏洞），如果将文本解释为 JavaScript 代码，那么浏览器将弹出 JavaScript Alert 窗口。当然，还有很多其他情形，因此，只测试这种情形是不够的。如您已经很了解的话，很可能将 JavaScript 注入请求的各种字段中：参数、HTTP 头，和路径。尽管，在一些情况下（特别是 HTTP Referer 头），很难利用浏览器执行攻击。
总结
跨站脚本攻击是黑客用来潜入 Web 应用程序的最普遍的应用程序层攻击之一，并且是最危险的手段之一。它是针对特殊 Web 站点的客户隐私的攻击，当客户详细信息失窃或受控时可能引发彻底的安全问题。不幸的是，如本文所阐述的，这种攻击经常在无需了解客户或被攻击组织情况的前提下就可以实现。
要防止 Web 站点受到这些恶意行为的攻击，至关重要的是，组织要实现在线和脱机的安全策略。这包括使用能够自动化测试出站点中所有普遍的 Web 安全漏洞，和具体应用程序的安全漏洞（例如跨站脚本）的自动化安全漏洞评估工具。对于全面的在线防卫，同样至关重要的是安装可以检测并抵御任何对保存在 Web 服务器上，或其背后的代码和内容实施控制的防火墙应用程序。
本文来自CSDN博客，转载请标明出处： http://blog.csdn.net/bill_lee_sh_cn/archive/2009/03/19/4005983.aspx