**
java - OutputStream.write() 期间持续发生 XSS 攻击
**
1 漏洞概述
我一直在研究有关持久 XSS 攻击的安全问题
将未经验证的数据发送到网络浏览器，这可能会导致浏览器执行恶意代码。
代码采用 Java 语言。
void output(OutputStream out){
out.write(byteData); //byteData is a data member of the class of type byte[].
}
在上面代码片段的第 (2) 行，我收到了 xss 攻击的通知。 那么我该如何验证它呢？
最佳答案
在将数据发送到 OutputStream 之前，您必须验证数据
void output(OutputStream out) {
// Validate byteData code here
out.write(byteData);
}
验证意味着检查代码是否遵守您要为其设置的规则。例如，如果您只想发送数字，则可以在发送之前确保您的 byteData 仅包含数字。
2 漏洞解决
Veracode报告说，我的应用程序在向outputStream写入文件流时存在XXS的风险。
public static int copyStream(InputStream in, OutputStream out, int buffer)
throws IOException {
byte buf[] = new byte[buffer];
int len;
int ttl = 0;
while ((len = in.read(buf)) != -1) {
try {
buf = ESAPI.validator().getValidFileContent(IOUtil.class.getName(), buf, 50000000, false);
out.write(buf, 0, len);
ttl += len;
} catch (IntrusionException e) {
e.printStackTrace();
} catch (ValidationException e) {
e.printStackTrace();
}
}
out.flush();
in.close();
out.close();
return ttl;
}
3 案例说明
1.1、产生原因：
- 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS（反射型），不可信赖的源通常为 Web 请求，只影响攻击到当前操作用户；而对于 Persisted（也称为 Stored 持久型）XSS，该源通常为数据库或其他后端数据存储，可能影响多操作用户。
- 未检验包含在动态内容中的数据，便将其传送给了 Web 用户。
传送到 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、对输出源进行校验和过滤；
例：
提供公共方法，结合实际业务需求，对输入源和输出源调用该方法进行特殊字符的过滤，主要是浏览器脚本可能包含的一些特殊字符。
过滤XSS攻击的特殊字符公共方法
我的公众号
后续操作请持续关注哦！！！
了解更多请关注下列公众号：
😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗😗😗😗😗😗😗😗😗
😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗 😗😗😗😗😗😗😗😗😗
————————————————
版权声明：本文为CSDN博主「永不垂头」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_45650712/article/details/120708376
