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

核心提示： 什么出了问题？很重要的是要知道，虽然 Web 站点不直接受到这种攻击的影响（站点继续正常工作，IBM Rational AppScan：跨站点脚本攻击深入解析(6)，恶意代码不在站点上执行，不会出现 DoS 情况，重要的是不向原始的输入字符串应用过滤，而只向输出版本应用过滤，并且数据不直接

什么出了问题？

很重要的是要知道，虽然 Web 站点不直接受到这种攻击的影响（站点继续正常工作，恶意代码不在站点上执行，不会出现 DoS 情况，并且数据不直接受控，或从站点上读取），但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志（security token）部署应用程序，借此，黑客可以猜出客户的安全标志并冒充客户。

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

如何保护站点不受 XSS 攻击

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

执行内部的输入过滤（有时候称为输入清洁设备）。对于内部书写的每个脚本中的每个用户输入 —— 参数或 HTTP 头，都应该应用高级的 HTML 标签（包括 JavaScript 代码）过滤。举例来说，来自之前的案例研究中的 welcome.cgi 脚本在解码 name 参数之后，应该过滤 <script> 标签。该方法有一些严重的不利因素：

它要求应用程序的编程人员非常精通安全。

它要求编程人员覆盖所有可能的输入来源（查询参数、POST 请求的 body 参数、HTTP 头）。

它不能抵御第三方脚本或服务器中的安全漏洞。举例来说，它不能防御 Web 服务器错误页面中的问题（通常显示了资源的路径）。

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