了解黑客如何启动跨站点脚本攻击（cross-site scripting，XSS），该攻击危害（及不危害）什么，如何检测它们，以及如何防止您的 Web 站点和站点的访问者受到这些针对隐私和安全的恶意入侵。
在跨站脚本攻击中会发生什么
跨站脚本攻击（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
|
响应是：
|
这是怎样被盗用的呢？黑客设法引诱受害客户点击他们提供给用户的链接。这是一个精心设计且蓄含恶意的链接，诱使受害者的 Web 浏览器访问站点（www.vulnerable.site），并调用入侵脚本。该脚本的数据里包含了用于非法访问客户端浏览器为 www.vulnerable.site 站点所存储 cookies 的 JavaScript。这是允许的，因为客户端浏览器“运行过”来自 www.vulnerable.site 的 JavaScript，并且 JavaScript 安全模型允许来自特殊站点的脚本访问属于该站点的 cookies。
这样的链接如下：
http://www.vulnerable.site/welcome.cgi?name=
|
受害者点击链接之后将生成对 www.vulnerable.site 的请求，如下所示：
GET /welcome.cgi?name= HTTP/1.0
Host: www.vulnerable.site ...
|
脆弱的站点的响应是：
|
受害者客户端的浏览器将把该响应解释为包含一段 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。
恶意的链接会是：
http://www.vulnerable.site/welcome.cgi?name=
|
响应页面看起来像这样：
|
加载该页面的浏览器会立即执行内嵌的 JavaScript，并向 www.attacker.site 中的 collect.cgi 脚本发送请求，并附带着浏览器已经拥有的 www.vulnerable.site 的 cookies 的值。这样就泄漏了客户端所拥有的 www.vulnerable.site 的 cookies。这将允许黑客冒充受害者。客户的隐私就完全被破坏了。
注意：
引发 JavaScript 弹出窗口的出现通常足够说明该站点容易受到 XSS 攻击。如果可以调用 JavaScript Alert 方法，那么通常没理由 window.open 调用不成功。这就是为什么大部分 XSS 攻击的实例使用 Alert 方法，因为这很容易检测其成功。
范围和可行性
攻击只会在受害者用于访问站点（www.vulnerable.site）的同一个浏览器中发生。黑客需要强迫客户端访问恶意链接。这会以以下这些方式进行：
- 黑客发送包含强迫浏览器访问该链接的 HTML 页面的电子邮件消息。这要求受害者使用 HTML 有效的电子邮件客户端，并且客户端的 HTML 阅读器是用于访问 www.vulnerable.site 的同一个浏览器。
- 客户端访问可能受黑客运作的站点，其中的图片链接或其他激活的 HTML 强迫浏览器访问该链接。再次声明，必须要求浏览器与访问该站点和 www.vulnerable.site 的是同一个浏览器。
恶意的 JavaScript 可以访问任何下列信息：
- 浏览器维护的（www.vulnerable.site 的）永久 cookies
- 浏览器实例维护的（www.vulnerable.site 的）RAM cookies，但只有当最近浏览 www.vulnerable.site 时发生。
- 为 www.vulnerable.site 打开的其他窗口的名称
- 可以通过当前的 DOM 访问的任何信息（如值、HTML 代码，等等）
身份识别、验证和授权标志通常以 cookies 形式维护。如果这些 cookies 是永久的，那么即使不在访问 www.vulnerable.site 的时候使用浏览器，受害者也是易受攻击的。然而，如果 cookies 是临时的，例如 RAM cookies，那么客户端必须处于访问 www.vulnerable.site 的会话中。
身份识别标志的另一种可能的实现是通过 URL 参数。在这种情况下，可以用这种方式使用 JavaScript 访问其他窗口（假设带有必要的 URL 参数的页面的名称为 foobar）：
|
跨站点脚本攻击的多种情形
除了 结果得到的 HTML 是： 执行传统的 XSS 攻击的其他方式 到此为止，我们已经看到 XSS 攻击可以出现在用脚本回送响应的 特别是，当错误页面返回错误的路径时，路径组件就有用了。在这种情况下，包含在该路径中的恶意脚本经常都会执行。已发现许多 Web 服务器都容易受到这种攻击。 什么出了问题？ 很重要的是要知道，虽然 Web 站点不直接受到这种攻击的影响（站点继续正常工作，恶意代码不在站点上执行，不会出现 DoS 情况，并且数据不直接受控，或从站点上读取），但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志（security token）部署应用程序，借此，黑客可以猜出客户的安全标志并冒充客户。 应用程序中的脆弱点是不管参数值是什么都回送参数的脚本。好的脚本确保参数的格式是适当的，包含合理的字符，等等。有效的参数通常没有合理的理由包含 HTML 标签或 JavaScript 代码，可靠起见，应该在这些内容嵌入响应之前，或者在应用程序中处理这些内容之前，将它们从参数中去掉。 如何保护站点不受 XSS 攻击 用这三种方式可以保护站点不受 XSS 攻击： 对每个脚本的每个参数（通过允许 JavaScript 的浏览器暴露出最简单类型的 XSS 安全漏洞），如果将文本解释为 JavaScript 代码，那么浏览器将弹出 JavaScript Alert 窗口。当然，还有很多其他情形，因此，只测试这种情形是不够的。如您已经很了解的话，很可能将 JavaScript 注入请求的各种字段中：参数、HTTP 头，和路径。尽管，在一些情况下（特别是 HTTP Referer 头），很难利用浏览器执行攻击。 总结 跨站脚本攻击是黑客用来潜入 Web 应用程序的最普遍的应用程序层攻击之一，并且是最危险的手段之一。它是针对特殊 Web 站点的客户隐私的攻击，当客户详细信息失窃或受控时可能引发彻底的安全问题。不幸的是，如本文所阐述的，这种攻击经常在无需了解客户或被攻击组织情况的前提下就可以实现。 要防止 Web 站点受到这些恶意行为的攻击，至关重要的是，组织要实现在线和脱机的安全策略。这包括使用能够自动化测试出站点中所有普遍的 Web 安全漏洞，和具体应用程序的安全漏洞（例如跨站脚本）的自动化安全漏洞评估工具。对于全面的在线防卫，同样至关重要的是安装可以检测并抵御任何对保存在 Web 服务器上，或其背后的代码和内容实施控制的防火墙应用程序。 ，黑客可以使用 ，还可以使用
...
">
...
GET 请求的参数中。但是也可以用 POST 请求实现攻击，或者利用 HTTP 请求的路径组件 —— 甚至使用一些 HTTP 头（例如 Referer）。
name 参数之后，应该过滤