漏洞警告：SpringBoot 该如何预防 XSS 攻击 ？？

写此文章的目的是为了记录一下在工作中解决的 XSS漏洞 问题。XSS漏洞是生产上比较常见的问题。虽然是比较常见并且是基本的安全问题，但是我们没有做🙄️ ，也怪我没有安全意识。于是终于有一天被制裁了。所以这次就补上了，记录一下。

看看问题

XSS 漏洞到底是什么，说实话我讲不太清楚。但是可以通过遇到的现象了解一下。在前端Form表单的输入框中，用户没有正常输入，而是输入了一段代码：</input><img src=1 onerror=alert1>这个正常保存没有问题。问题出在了列表查询的时候，上面的代码就生效了，由于图片的地址乱写的，所以这个alert就起作用了来看图。

那根据这个原理，实际上如果没有做任何的限制，有心人就可以为所欲为了。可以在里面嵌入一些关键代码，把你的信息拿走。确实是个很严重的问题。

解决思路

既然是因为输入框中输入了不该输入的东西，那自然就萌生一些想法：

• 校验输入内容，不允许用户输入特殊字符，特殊标签

• 允许用户输入，但是保存的时候将特殊的字符直接替换为空串

• 允许用户输入，将特殊字符转译保存。

第一种方法，特殊字符过滤。既然要过滤特殊字符，那就得自己把所有的特殊字符列出来进行匹配，比较麻烦，而且要定义好什么才是特殊字符？况且用户本身不知道什么是特殊字符。突如其来的报错，会让用户有点摸不着头脑，不是很友好。

第二种方法，特殊字符替换为空串。未免有点太暴力。万一真的需要输入一点特殊的字符，保存完查出来发现少了好多东西，人家以为我们的BUG呢。也不是很好的办法。

第三种办法，特殊字符转译。这个办法不但用户数据不丢失，而且浏览器也不会执行代码。比较符合预期。

那办法确定了，怎么做呢？前端来做还是后端来做？想了想还是要后端来做。毕竟使用切面或者Filter可以一劳永逸。

心路历程

经过抄袭，我发现了一些问题，也渐渐的有了一些理解。下面再说几句废话：

查到的预防XSS攻击的，大多数的流程是：

• 拦截请求

• 重新包装请求

• 重写HttpServletRequest中的获取参数的方法

• 将获得的参数进行XSS处理

• 拦截器放行

于是我就逮住一个抄了一下。抄袭完毕例行测试，发现我用@RequestBody接受的参数，并不能过滤掉特殊字符。怎么肥四？大家明明都这么写。为什么我的不好使？

这个时候突然一个想法萌生。SpringMVC在处理@RequestBody类型的参数的时候，是不是使用的我重写的这些方法呢？（getQueryString()、getParameter(String name)、getParameterValues(String name)、getParameterMap()）。打了个日志，发现还真不是这些方法。

于是搜索了一下Springboot拦截器获取@RequestBody参数，碰到了这篇文章。首先的新发现是Spring MVC 在获取@RequestBody参数的时候使用的是getInputStream()方法。嗯？（斜眼笑）那我是不是可以重写这个方法获取到输入流的字符串，然后直接处理一下？

说干就干，一顿操作。进行测试。发现直接JSON 转换的报错了。脑裂。估计是获得的字符串在转换的时候把不该转的东西转译了，导致不能序列化了。眼看就要成功了，一测回到解放前。

该怎么办呢？其实思路是没错的，就是在获取到流之后进行处理。但是错就错在处理的位置。果然处理的时间点很重要。（就像伴侣一样，某人出现的时间点很重要）。那既然不能在现在处理，那就等他序列化完毕之后再处理就好了。那怎么办呢？难道要写一个AOP 拦截到所有的请求？用JAVA反射处理？

正在迷茫的时候，看到了一篇文章，知识增加了。原来可以在序列化和反序列化的时候进行处理。

最终实现

看一下最终的代码实现（有些导入的包被我删了）

重新包装Request的代码

import org.apache.commons.text.StringEscapeUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.servlet.ReadListener;
import javax.servlet.ServletInputStream;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
import java.io.BufferedReader;
import java.io.ByteArrayInputStream;
import java.io.IOEx