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

发布: 2008-8-28 15:07 | 作者: Ory Segal | 来源: 测试时代采编 | 查看: 516次 | 进入软件测试论坛讨论

用这三种方式可以保护站点不受 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 服务器上，或其背后的代码和内容实施控制的防火墙应用程序。