Cross-Site Scripting: Reflected

首先贴解决办法吧，解决了我项目中的问题，不一定适用所有情况。

        //For Cross-Site Scripting: Reflected
      public static String filter(String output){
          List<String> list = new ArrayList<String>();
          list.add("<");
          list.add(">");
          list.add("(");
          list.add(")");
          list.add("&");
          list.add("?");
          list.add(";");
          String encode= Normalizer.normalize(output,Normalizer.Form.NFKC);
          for(int i = 0; i<list.size();i++){
              encode=encode.replace(list.get(i),"");
          }
      return encode;
      }

//需要校验的内容
response.getWriter().write(XXXX.filter(XXX));

假如解决不了 就只能仔细研究下文档中内容了，再结合自己的代码做检验。↓

--------------------------------------------------------------------------------------------------------------------------------

Cross-Site Scripting: Reflected

Abstract

向Web浏览器发送未经验证的数据可能会导致浏览器执行恶意代码

Explanation

跨站点脚本(XSS)漏洞发生在以下情况：1.数据通过不可信的来源进入Web应用程序。在反射XSS的情况下，不受信任的源通常是Web请求，而在持久化(也称为存储)XSS的情况下，
它通常是数据库或其他后端数据存储。2.数据包括在动态内容中，该动态内容在未经验证的情况下被发送给web用户。发送到Web浏览器的恶意内容通常采用JavaScript片段的形
式，但也可能包括HTML、Flash或浏览器可能执行的任何其他类型的代码。基于XSS的攻击种类几乎是无限的，但它们通常包括向攻击者传输Cookie或其他会话信息等私人数据，将
受害者重定向到攻击者控制的Web内容，或者以易受攻击的站点为幌子在用户计算机上执行其他恶意操作。示例1：下面的JSP代码段从HTTP请求中读取员工ID EID，并将其显示给
用户。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

如果EID仅包含标准字母数字文本，则此示例中的代码可以正常运行。如果EID具有包含元字符或源代码的值，则代码将由Web浏览器在显示HTTP响应时执行。起初，这可能看起来不
是一个很大的漏洞。毕竟，为什么有人要输入一个导致恶意代码在他们自己的计算机上运行的URL呢？真正的危险在于，攻击者会创建恶意URL，然后使用电子邮件或社会工程技巧引
诱受害者访问指向该URL的链接。当受害者单击该链接时，他们会在不知不觉中通过易受攻击的Web应用程序将恶意内容反映回自己的计算机。这种利用易受攻击的Web应用程序的机
制称为反射XSS。示例2：下面的JSP代码段在数据库中查询具有给定ID的员工，并打印相应员工的姓名。

<%... Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>

与示例1中一样，当name的值行为良好时，此代码可以正常工作，但如果不是这样，它不会阻止利用漏洞。同样，此代码看起来不那么危险，因为name的值是从数据库读取的，数据库的内容
显然由应用程序管理。但是，如果Name的值来自用户提供的数据，则数据库可能是恶意内容的管道。如果没有对存储在数据库中的所有数据进行正确的输入验证，攻击者可能会在用户的Web
浏览器中执行恶意命令。这种类型的利用称为持久(或存储的)XSS，特别隐蔽，因为数据存储导致的间接攻击使识别威胁变得更加困难，并增加了攻击影响多个用户的可能性。XSS开始于这种
形式的网站，向访问者提供“留言簿”。攻击者会在他们的留言簿条目中包含JavaScript，所有随后访问留言簿页面的访问者都会执行恶意代码。一些人认为，在移动世界中，传统的Web应
用程序漏洞，如跨站点脚本，是没有意义的--为什么用户要攻击他们自己呢？但是，请记住，移动平台的本质是从各种来源下载并在同一设备上并行运行的应用程序。在银行应用程序旁边运
行恶意软件的可能性很高，这就需要扩大移动应用程序的攻击面，以包括进程间通信。

示例3：以下代码在Android的WebView中启用JavaScript(默认关闭JavaScript)，并根据从Android Intent接收的值加载页面。

...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...

如果url的值以javascript：开头，则随后的JavaScript代码将在WebView内的网页上下文中执行。如示例所示，XSS漏洞是由HTTP响应中包含未经验证的数据的代码引起的。XSS攻击可
以通过三个向量到达受害者：-如示例1所示，数据直接从HTTP请求中读取并反映回HTTP响应中。当攻击者使用户向易受攻击的Web应用程序提供危险内容，然后将其反射回用户并由Web浏览器
执行时，就会发生反射的XSS利用漏洞攻击。传递恶意内容的最常见机制是将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的URL中。以这种方式构建的URL构成了许多网络钓鱼
计划的核心，攻击者据此说服受害者访问指向易受攻击站点的URL。在站点将攻击者的内容反映回用户之后，该内容将被执行，并继续将私人信息(例如可能包含会话信息的cookie)从用户的计
算机传输到攻击者或执行其他恶意活动。-如示例2所示，应用程序将危险数据存储在数据库或其他受信任的数据存储中。危险数据随后被读回应用程序并包括在动态内容中。当攻击者将危险内容
注入稍后读取并包含在动态内容中的数据存储中时，就会发生持久的XSS攻击。从攻击者的角度来看，注入恶意内容的最佳位置是向许多用户或特别感兴趣的用户显示的区域。感兴趣的用户通常在
应用程序中拥有提升的权限，或者与对攻击者有价值的敏感数据交互。如果其中一个用户执行恶意内容，攻击者可能能够代表该用户执行特权操作或访问属于该用户的敏感数据。-如示例3所示，应
用程序外部的源将危险数据存储在数据库或其他数据存储中，然后将危险数据作为可信数据读回应用程序，并将其包括在动态内容中。许多现代Web框架提供用于执行用户输入验证的机制。
Struts和Spring MVC都在其中。为了突出显示未经验证的输入源，规则包通过降低HPE Security Fortify静态代码分析器报告的问题的利用概率，并在使用框架验证机制时提供指向支
持证据的指针，动态地重新确定问题的优先级。我们将此功能称为上下文敏感排名。为了进一步帮助HPE Security Fortify用户执行审核流程，HPE Security Fortify软件安全研究小
组提供了数据验证项目模板，该模板根据应用于其输入源的验证机制将问题分组到文件夹中。

Recommendation

XSS的解决方案是确保验证在正确的位置进行，并检查正确的属性。由于当应用程序在其输出中包含恶意数据时会出现XSS漏洞，因此一种合乎逻辑的方法是在数据离开应用程序之前立即对其进行
验证。然而，由于Web应用程序通常具有复杂而复杂的代码来生成动态内容，因此此方法容易出现遗漏错误(缺少验证)。降低此风险的有效方法是还对XSS执行输入验证。Web应用程序必须验证其
输入以防止其他漏洞(如SQL注入)，因此扩展应用程序的现有输入验证机制以包括对XSS的检查通常相对容易。尽管XSS的输入验证很有价值，但它并不能取代严格的输出验证。应用程序可以通过
共享数据存储或其他可信来源接受输入，并且该数据存储可以接受来自没有执行充分输入验证的源的输入。因此，应用程序不能隐式依赖此数据或任何其他数据的安全性。这意味着防止XSS漏洞的
最好方法是验证进入应用程序并将应用程序留给用户的所有内容。对XSS进行验证的最安全方法是创建允许出现在HTTP内容中的安全字符的白名单，并接受仅由批准的集合中的字符组成的输入。
例如，有效的用户名可能只包括字母数字字符，或者电话号码可能只包括数字0-9。然而，此解决方案在以下方面通常是不可行的Web应用程序，因为许多对浏览器有特殊意义的字符在编码后仍应被
视为有效输入，例如必须接受来自其用户的HTML片段的Web设计公告栏。一种更灵活但不太安全的方法被称为黑名单，它在使用输入之前有选择地拒绝或转义潜在的危险字符。为了形成这样的列表
，您首先需要了解对Web浏览器具有特殊含义的字符集。虽然HTML标准定义了哪些字符有特殊含义，但许多Web浏览器试图纠正HTML中的常见错误，并可能在某些上下文中将其他字符视为特殊字符
，这就是为什么我们不鼓励使用黑名单作为防止XSS的手段。卡内基梅隆大学(Carnegie Mellon University)软件工程学院的CERT(R)协调中心提供了关于各种上下文中的特殊字符的以
下详细信息[1]：在块级元素的内容中(在文本段落的中间)：-“<”是特殊的，因为它引入了一个标签。-“&”是特殊的，因为它引入了一个字符实体。-“>”是特殊的，因为一些浏览器将其视为特殊的
，假设页面的作者打算包括开头的“<”，但错误地遗漏了它。以下原则适用于属性值：-在用双引号括起来的属性值中，双引号是特殊的，因为它们标记属性值的结束。-在用单引号括起来的属性值中，
单引号是特殊的，因为它们标记属性值的末尾。-在不带引号的属性值中，空格和制表符等空格字符是特殊字符。-“&”在与某些属性一起使用时是特殊的，因为它引入了一个字符实体。例如，在URL
中，搜索引擎可能会在结果页内提供一个链接，用户可以单击该链接以重新运行搜索。这可以通过在URL中编码搜索查询来实现，这引入了额外的特殊字符：-空格、制表符和换行符是特殊的，因为它
们标记URL的末尾。-“&”是特殊的，因为它要么引入一个字符实体，要么分隔CGI参数。-URL中不允许使用非ASCII字符(即ISO-8859-1编码中所有大于128的字符)，因此在此上下文中它们被
视为特殊字符。-在服务器端代码解码使用HTTP转义序列编码的参数时，必须从输入中过滤“%”符号。例如，如果“%68%65%6C%6C%6C%6F”之类的输入在相关网页上显示为“hello”，则必须过滤
“%”。在正文中：-分号、圆括号、大括号和换行符应该在文本可以直接插入到预先存在的脚本标记的情况下过滤掉。服务器端脚本：-转换任何感叹号(！)的服务器端脚本。在输入到输出上的双引号字
符(“)时，可能需要额外的筛选。其他可能性：-如果攻击者以UTF-7格式提交请求，则特殊字符“<”将显示为“+adw-”，并可能绕过过滤。如果输出包含在没有显式指定编码格式的页面中，那么一些
浏览器会尝试根据内容(在本例中为UTF-7)智能地识别编码。一旦您确定了应用程序中正确的点来执行XSS攻击验证，以及验证应该考虑哪些特殊字符，下一个挑战就是确定您的验证如何处理特殊字
符。如果特殊字符不被视为应用程序的有效输入，则可以拒绝任何包含特殊字符的无效输入。这种情况下的第二个选项是使用过滤删除特殊字符。然而，过滤具有改变过滤内容的任何可视表示的副作用
，并且在必须保留输入完整性以供显示的情况下可能是不可接受的。如果必须接受和准确显示包含特殊字符的输入，则验证必须对任何特殊字符进行编码以消除其重要性。特殊字符的ISO 8859-1编
码值的完整列表作为官方HTML规范的一部分提供[2]。许多应用程序服务器试图通过提供负责设置某些特定HTTP响应内容的函数的实现来限制应用程序暴露于跨站点脚本漏洞，这些特定HTTP响应
内容对跨站点脚本攻击所必需的字符执行验证。不要依赖运行应用程序的服务器来确保应用程序的安全。在开发应用程序时，无法保证它在其生命周期内将在哪些应用程序服务器上运行。随着标准和
已知漏洞的发展，不能保证应用程序服务器也会保持同步。