书接上文，继续对Fortify漏洞进行总结，本篇主要针对XSS跨站脚步攻击漏洞进行总结如下：
1、Cross-Site Scripting（XSS 跨站脚本攻击）
1.1、产生原因：
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS（反射型），不可信赖的源通常为 Web 请求，只影响攻击到当前操作用户；而对于 Persisted（也称为 Stored 持久型）XSS，该源通常为数据库或其他后端数据存储，可能影响多操作用户。
2. 未检验包含在动态内容中的数据，便将其传送给了 Web 用户。
图1.1.1 XSS漏洞分类
传送到 Web 浏览器的恶意内容通常采用 JavaScript 代码片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私人数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。
示例 1：以下代码可从 HTTP servlet 请求中读取雇员 ID eid，并在 servlet 响应中将值显示给该用户。
String eid = request.getParameter("eid");
...
ServletOutputStream out = response.getOutputStream();
out.print("Employee ID: " +
eid);
...
out.close();
...
如果 eid 只包含标准的字母或数字文本，这个例子中的代码就能正确运行。如果 eid 里有包含元字符或源代码中的值，那么 Web 浏览器就会像显示 HTTP 响应那样执行代码。
起初，这个例子似乎是不会轻易遭受攻击的。毕竟，有谁会输入导致恶意代码的 URL，并且还在自己的电脑上运行呢？真正的危险在于攻击者会创建恶意的 URL，然后采用电子邮件或者社会工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时，他们不知不觉地通过易受攻击的网络应用程序，将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2：以下代码片段可在数据库中查询具有给定 ID 的雇员，并在 servlet 响应中输出相应雇员姓名。
...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name =
rs.getString("name");
}
ServletOutputStream out = response.getOutputStream();
out.print("Employee Name: " + name);
...
out.close();
...
如同例 1，如果对 name 的值处理得当，该代码就能正常地执行各种功能；如若处理不当，就会对代码的盗取行为无能为力。同样，这段代码暴露出的危险较小，因为 name的值是从数据库中读取的，而且显然这些内容是由应用程序管理的。然而，如果 name 的值是由用户提供的数据产生，数据库就会成为恶意内容沟通的通道。如果不对数据库中存储的所有数据进行恰当的输入验证，那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的 Persistent XSS（也称为 Stored XSS）盗取极其阴险狡猾，因为数据存储导致的间接性使得辨别威胁的难度增大，而且还提高了一个攻击影响多个用户的可能性。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript，接下来所有访问该留言簿的用户都会执行这些恶意代码。
1.2、修复方案：
所以根据XSS漏洞产生的原因，对于XSS脚本攻击的漏洞修复，主要解决方案是：
a、对输入源进行校验和过滤；
b、对输出源进行校验和过滤；
例：
提供公共方法，结合实际业务需求，对输入源和输出源调用该方法进行特殊字符的过滤，主要是浏览器脚本可能包含的一些特殊字符。
图1.1.2：过滤XSS攻击的特殊字符公共方法
原文地址：https://www.cnblogs.com/meInfo/p/9004535.html