执行传统的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服务器上，或其背后的代码和内容实施控制的防火墙应用程序。
