1. 项目概述为什么你的SpringBoot应用需要一个XSS过滤器做Web开发这些年我见过太多因为XSS跨站脚本攻击漏洞导致的“惨案”。从用户留言板里突然弹出的恶作剧弹窗到被悄无声息盗走的用户Cookie再到页面被恶意跳转到钓鱼网站这些问题的根源往往不是业务逻辑有多复杂而是开发者在处理用户输入时少了一层“净化”的工序。尤其是在SpringBoot这种快速开发框架下我们往往专注于实现业务功能却容易忽略Web安全这个基础防线。XSS攻击的原理其实不复杂简单说就是攻击者把恶意脚本代码“混”在正常的用户输入里比如评论、昵称、搜索关键词提交给服务器。如果服务器没有对这些输入进行过滤或转义就直接存储并展示给其他用户那么其他用户的浏览器就会把这些恶意脚本当作正常的页面代码来执行。这就好比你把一个陌生人递过来的、没经过安检的包裹直接放进了自己家风险可想而知。SpringBoot项目实战中集成一个全局的XSS防御机制是每个项目上线前必须完成的“规定动作”。今天要聊的就是一个能在5分钟内为你的SpringBoot应用“穿上防弹衣”的实战方案。它不依赖任何重量级的安全框架核心就是一个自定义的过滤器Filter配合一个精心编写的HTML过滤器实现对请求参数的全局清洗。我会把完整的、可运行的代码示例拆开揉碎了讲给你听从原理到避坑保证你拿过去就能用。2. XSS攻击的本质与SpringBoot的防御盲区在动手写代码之前我们必须先搞清楚敌人是谁以及我们现有的防御体系哪里最薄弱。很多开发者以为用了SpringBoot安全就高枕无忧了其实不然。2.1 XSS攻击的三种常见“姿势”XSS攻击主要分为三类反射型、存储型和DOM型。我们的防御方案需要能覆盖前两种最常见的情况。反射型XSS这种攻击像是“一次性钓鱼”。恶意脚本作为请求参数比如在URL里发送给服务器服务器未经处理就直接把参数内容嵌入了响应页面中。典型的场景是搜索框攻击者构造一个包含恶意脚本的搜索链接发给受害者受害者一点击脚本就在其浏览器中执行了。它的数据不存储在服务器端。存储型XSS这才是“心腹大患”。攻击者将恶意脚本提交到服务器比如写入数据库的论坛帖子、用户昵称当其他用户浏览到这些被“污染”的数据时脚本就会执行。它的危害是持久性的影响所有访问相关页面的用户。DOM型XSS这种攻击发生在客户端恶意脚本通过修改页面的DOM结构来实施不经过服务器端处理。防御它主要靠前端对innerHTML、document.write等危险操作的谨慎使用以及实施严格的CSP内容安全策略。我们今天的服务器端过滤器对它的直接防御有限但良好的编码习惯可以避免。2.2 SpringBoot的默认安全配置与我们的需求Spring Boot Security 确实提供了一套强大的安全框架但它更侧重于身份认证Authentication和授权Authorization比如防止未登录访问、控制页面权限。对于XSS这种“输入净化”层面的问题它并没有开箱即用的、针对请求体内容进行字符串级别过滤的全局解决方案。我们常见的做法是在每个Controller的方法参数里用RequestParam或RequestBody接收数据后手动调用工具类进行转义。这种方法有两大弊端一是容易遗漏哪个开发人员敢保证自己每次都能记得二是代码侵入性强业务代码里混杂着安全逻辑不优雅。因此我们需要一个全局的、非侵入的、对业务透明的解决方案。过滤器Filter正是Servlet规范中用于在请求到达Servlet之前和响应发出之后进行处理的组件它是实现这个需求的绝佳位置。我们的目标就是创建一个XSS过滤器在HTTP请求刚进入应用时就对所有参数进行“消毒”处理。3. 核心防御方案设计全局过滤器的实现思路整个防御体系的核心是一个自定义的XssFilter和一个包装了HttpServletRequest的XssHttpServletRequestWrapper。思路是“偷梁换柱”当请求经过我们的过滤器时我们不把原始的HttpServletRequest对象传递给后面的Controller而是传递一个被我们包装过的、重写了关键方法如getParametergetInputStream的对象。这样Controller从请求对象中获取的任何参数都已经是经过我们清洗过的“安全数据”。3.1 方案选型为什么是过滤器而不是拦截器或AOP这里可能有人会问Spring里不是还有拦截器Interceptor和面向切面编程AOP吗为什么偏偏选过滤器执行时机最早Filter是Servlet层面的组件它的执行在Spring MVC的DispatcherServlet之前。这意味着在请求进入Spring框架之前我们就能完成过滤范围最广能处理静态资源请求等。对请求体Request Body处理更友好拦截器和AOP通常作用于Controller方法被调用时此时请求参数可能已经被Spring MVC的HttpMessageConverter如处理JSON的MappingJackson2HttpMessageConverter解析成了Java对象。要修改这些对象里的数据比较麻烦。而过滤器可以在流级别直接对原始的请求体数据进行处理。更通用Filter是Java EE标准不依赖于Spring理论上更通用。虽然我们在Spring Boot里用但这个思想可以迁移。当然这个方案也有一个需要特别注意的点请求体InputStream在Servlet规范中默认只能读取一次。我们的包装器需要读取流并进行清洗那么后续的Controller或框架再读取时就会遇到流已关闭的问题。因此我们必须在包装器里把清洗后的数据缓存起来并提供一个可以重复读取的InputStream。这是实现过程中的一个关键细节。3.2 整体架构与流程整个方案的代码结构清晰主要包含以下几个部分XssFilter入口过滤器负责判断当前请求是否需要过滤比如排除一些特定的URL并将原请求对象替换为我们的包装器。XssHttpServletRequestWrapperHttpServletRequestWrapper的子类。这是核心我们通过重写getParameter、getParameterValues、getHeader、getInputStream等方法在这些方法返回数据前插入我们的清洗逻辑。EscapeUtil / HTMLFilter实际的清洗工具类。EscapeUtil提供简单的转义Escape和清理Clean方法。HTMLFilter则是一个更复杂的、可配置的HTML标签过滤器它可以根据白名单决定保留哪些安全的HTML标签和属性。FilterConfigSpring Boot配置类用于将我们自定义的XssFilter注册到Spring容器中并可以通过application.yml配置文件来灵活控制过滤器的开关、排除的URL等。流程图可以简单理解为HTTP Request-XssFilter- (如果需要过滤) 将Request对象替换为XssHttpServletRequestWrapper-Spring MVC DispatcherServlet-Controller。Controller感知不到包装过程它拿到的一切参数都是干净的。4. 代码逐行精讲与避坑指南接下来我们深入到代码内部。我会把核心代码拆解出来并附上我实际项目中踩过的坑和总结的经验。4.1 基石HTML过滤工具类HTMLFilter这个类是整个清洗逻辑的发动机。它来自开源项目OWASP Java HTML Sanitizer的思想是一个功能相对完善的白名单过滤器。代码较长但核心逻辑是使用正则表达式匹配HTML标签和属性然后根据预定义的白名单决定是保留、移除还是转义。关键配置点在无参构造函数中public HTMLFilter() { vAllowed new HashMap(); final ArrayListString a_atts new ArrayList(); a_atts.add(href); a_atts.add(target); // 允许a标签有href和target属性 vAllowed.put(a, a_atts); final ArrayListString img_atts new ArrayList(); img_atts.add(src); img_atts.add(width); img_atts.add(height); img_atts.add(alt); // 允许img标签有这些属性 vAllowed.put(img, img_atts); // 允许b, strong, i, em标签但不允许它们有任何属性空列表 final ArrayListString no_atts new ArrayList(); vAllowed.put(b, no_atts); vAllowed.put(strong, no_atts); vAllowed.put(i, no_atts); vAllowed.put(em, no_atts); vSelfClosingTags new String[] { img }; // 自闭合标签 vNeedClosingTags new String[] { a, b, strong, i, em }; // 需要闭合的标签 vAllowedProtocols new String[] { http, mailto, https }; // 链接允许的协议 // ... 其他配置 }实操心得1白名单策略比黑名单更可靠千万不要试图列一个“所有危险标签”的黑名单去过滤因为HTML和JavaScript的变形组合方式太多了比如大小写混合、嵌套无效标签、利用HTML实体编码等防不胜防。最安全的做法是采用白名单只允许已知安全的标签和属性通过。上面的配置就是一个非常保守的白名单只允许一些基本的、用于排版的标签。对于富文本编辑器如博客内容的场景你需要根据业务需求谨慎地扩充这个白名单比如增加p,span,ul,li等但一定要避免加入script,style,iframe,onclick这类高危标签或事件属性。实操心得2注意JSON数据中的双引号在HTMLFilter的encodeQuotes方法中有一段注释“不替换双引号为quot;防止json格式无效”。这是因为JSON格式严格依赖双引号来包裹属性名和字符串值。如果我们将双引号转义会导致后续的Jackson等JSON解析器报错。因此在过滤JSON请求体时这个细节至关重要。我们的清洗策略是移除或转义整个脚本标签而不是破坏JSON的结构。4.2 核心包装器XssHttpServletRequestWrapper这个类是拦截和清洗数据的关键。它继承了HttpServletRequestWrapper可以重写父类的方法。public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } Override public String[] getParameterValues(String name) { String[] values super.getParameterValues(name); if (values ! null) { String[] escapesValues new String[values.length]; for (int i 0; i values.length; i) { // 关键清洗操作清理XSS并去除前后空格 escapesValues[i] EscapeUtil.clean(values[i]).trim(); } return escapesValues; } return super.getParameterValues(name); } Override public ServletInputStream getInputStream() throws IOException { // 1. 判断是否为JSON请求 if (!isJsonRequest()) { return super.getInputStream(); // 非JSON按普通请求处理如果需要过滤普通表单可在此扩展 } // 2. 读取原始请求体 String json IOUtils.toString(super.getInputStream(), StandardCharsets.UTF_8); if (StringUtils.isEmpty(json)) { return super.getInputStream(); } // 3. 对JSON字符串进行XSS清洗 json EscapeUtil.clean(json).trim(); // 4. 将清洗后的字符串重新封装为InputStream byte[] jsonBytes json.getBytes(StandardCharsets.UTF_8); final ByteArrayInputStream bis new ByteArrayInputStream(jsonBytes); return new ServletInputStream() { // ... 实现InputStream的抽象方法基于bis操作 Override public int read() throws IOException { return bis.read(); } // ... isFinished, isReady, setReadListener 等方法 }; } // ... 同样需要重写 getParameter, getHeader 等方法 }避坑指南1请求体只能读一次这是实现中最容易出错的地方。HttpServletRequest的getInputStream()方法返回的流默认只能读取一次。在我们的getInputStream()方法里我们通过IOUtils.toString把流读完了那么后续Spring MVC框架来解析RequestBody时就会拿到一个空流。所以我们必须把清洗后的JSON字符串jsonBytes缓存到一个新的ByteArrayInputStream中并返回这个新流的包装。这样无论后面读多少次数据都还在。避坑指南2区分请求类型我们重写的getInputStream()中首先判断!isJsonRequest()。这里假设只有Content-Type为application/json的请求体需要特殊处理因为要保护JSON结构。对于传统的application/x-www-form-urlencoded表单提交其参数是通过getParameter()方法获取的已经在上面重写的方法里处理了。如果你的应用还有multipart/form-data文件上传需要额外注意文件内容本身通常不需要进行HTML清洗但文件名Filename可能需要。这部分可以根据业务情况在过滤器中排除或单独处理。4.3 入口与调度XssFilter 与 FilterConfigXssFilter是过滤器的实现它决定哪些请求需要被处理。public class XssFilter implements Filter { private ListString excludes new ArrayList(); // 排除的URL模式 Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; if (handleExcludeURL(req)) { chain.doFilter(request, response); // 直接放行 return; } // 使用包装器 XssHttpServletRequestWrapper xssRequest new XssHttpServletRequestWrapper(req); chain.doFilter(xssRequest, response); } private boolean handleExcludeURL(HttpServletRequest request) { String url request.getServletPath(); String method request.getMethod(); // 示例GET和DELETE请求不过滤根据场景决定通常GET也可能有XSS风险 if (method null || HttpMethod.GET.matches(method) || HttpMethod.DELETE.matches(method)) { return true; } // 检查是否在排除列表里 return StringUtils.matches(url, excludes); } }FilterConfig是Spring Boot的配置类用于将过滤器注入到Servlet容器。Configuration public class FilterConfig { Value(${xss.enabled:true}) private String enabled; Value(${xss.excludes:/system/notice,/api/upload}) private String excludes; Value(${xss.urlPatterns:/*}) private String urlPatterns; Bean ConditionalOnProperty(value xss.enabled, havingValue true) public FilterRegistrationBeanXssFilter xssFilterRegistration() { FilterRegistrationBeanXssFilter registration new FilterRegistrationBean(); registration.setFilter(new XssFilter()); registration.addUrlPatterns(StringUtils.split(urlPatterns, ,)); registration.setName(xssFilter); registration.setOrder(Ordered.HIGHEST_PRECEDENCE); // 设置最高优先级确保最先执行 MapString, String initParameters new HashMap(); initParameters.put(excludes, excludes); registration.setInitParameters(initParameters); return registration; } }配置经验ConditionalOnProperty这个注解非常好用它允许我们通过application.yml中的xss.enabled开关来动态启用或禁用整个过滤器。在测试环境或排查问题时可以临时关闭。Ordered.HIGHEST_PRECEDENCE将过滤器的执行顺序设为最高。这很重要要确保我们的清洗操作在其他可能修改请求的过滤器比如字符编码过滤器之后执行但在Spring Security等安全框架之前执行。顺序不对可能导致清洗失效或引发其他问题。排除列表excludes一定要留出排除接口。例如某些接受富文本HTML内容如文章发布的接口或者文件上传接口我们可能不希望进行严格的标签过滤而是交由更专门的内容审核或前端渲染库处理。对应的application.yml配置xss: enabled: true excludes: /system/notice,/api/rich-text/save # 多个路径用逗号分隔 urlPatterns: /* # 默认过滤所有请求5. 完整集成、测试与效果验证现在我们把所有零件组装起来并在一个Spring Boot项目中测试。5.1 项目结构与依赖创建一个标准的Spring Boot项目确保pom.xml中包含Web依赖。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 可选用于测试 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency将前面提到的HTMLFilter、EscapeUtil、XssHttpServletRequestWrapper、XssFilter、FilterConfig等类放入你的项目源码目录中。通常过滤器相关类放在com.yourproject.filter包下工具类放在com.yourproject.utils包下。5.2 编写测试Controller我们创建一个简单的Controller来验证过滤效果。RestController Slf4j public class TestController { // 测试1普通表单POST参数会被过滤 PostMapping(/test/form) public String testForm(RequestParam String content) { log.info(接收到的内容: {}, content); // 观察日志这里的content应该是被清洗过的例如scriptalert(1)/script会被过滤掉标签 return 处理后的内容: content; } // 测试2JSON格式POST请求体会被过滤 PostMapping(/test/json) public User testJson(RequestBody User user) { log.info(接收到的用户: {}, user); // 观察日志user对象的所有字符串字段都应该被清洗过 return user; } // 测试3被排除的接口内容原样返回 PostMapping(/system/notice) public String notice(RequestParam String htmlContent) { log.info(公告接口接收HTML: {}, htmlContent); // 这个接口在excludes列表里不会触发XSS过滤 return htmlContent; } Data // 使用Lombok注解 public static class User { private String username; private String email; private String bio; // 个人简介可能包含HTML } }5.3 使用Postman或CURL进行测试测试用例1反射型XSS攻击模拟向/test/form发送一个POST请求表单数据为contentscriptalert(xss)/script。预期结果在Controller里打印的日志和返回的响应中script和/script标签应该被移除只剩下alert(xss)这段文本。你的浏览器不会弹出警告框。测试用例2存储型XSS攻击模拟JSON向/test/json发送一个POST请求JSON体为{ username: hackerscriptalert(1)/script, email: testexample.com, bio: img srcx onerroralert(\gotcha\) / }预期结果username字段中的script标签被移除。bio字段中的img标签如果不在白名单内或者onerror属性不被允许整个标签会被移除或净化。返回的JSON对象中这些危险内容已不存在。测试用例3验证排除功能向/system/notice发送一个POST请求内容为p这是一个b加粗/b的公告/p。预期结果因为该接口在排除列表里所以内容不会被HTMLFilter处理原样到达Controller。这对于需要保存原始HTML的富文本编辑器接口是必要的。5.4 效果验证与日志分析启动你的Spring Boot应用运行上述测试。通过查看Controller中打印的日志你可以清晰地看到过滤前后的区别。例如对于测试用例1你的日志输出可能类似于接收到的内容: alert(xss)而不是接收到的内容: scriptalert(xss)/script这就证明我们的过滤器生效了恶意脚本标签已被成功剥离。6. 进阶考量与生产环境部署建议把代码跑起来只是第一步要真正用到生产环境还需要考虑更多细节。6.1 性能影响与优化字符串过滤尤其是复杂的正则表达式匹配肯定会有性能开销。我们需要将其降到最低。优化HTMLFilter原版的HTMLFilter使用了大量的正则表达式编译Pattern.compile。这些Pattern对象应该声明为static final常量在类加载时就初始化好避免每次过滤都重新编译。上面给出的代码示例已经做到了这一点。缩小过滤范围通过urlPatterns和excludes精确控制需要过滤的接口。对于只返回静态数据、无需用户输入的API可以排除。考虑缓存对于频繁出现的、相同的恶意模式可以考虑使用简单的缓存但要注意缓存污染和内存消耗。6.2 与其他安全机制的协同XSS防御不是孤立的它应该是一个纵深防御体系的一部分。输出编码我们的过滤器主要做输入过滤。但更安全的做法是输入验证输出编码。在某些场景下我们可能需要存储原始数据比如富文本那么在输出到HTML页面时必须使用正确的编码函数如Thymeleaf的th:text会自动转义th:utext则不会要慎用。对于非HTML的输出如JSON API要设置正确的Content-Type防止浏览器误解析为HTML。CSP内容安全策略在HTTP响应头中加入CSP策略是防御XSS的终极利器之一。它可以告诉浏览器只允许加载指定来源的脚本、样式等资源即使有恶意脚本被注入浏览器也不会执行。例如Content-Security-Policy: default-src self。这可以作为我们过滤器方案的有力补充。HttpOnly Cookie对于会话Cookie务必设置HttpOnly属性。这样即使网站存在XSS漏洞导致脚本被执行该脚本也无法通过document.cookie读取到Cookie信息从而防止会话劫持。6.3 常见问题排查FAQ在实际部署中你可能会遇到下面这些问题Q1过滤器导致我的JSON请求报错“HttpMessageNotReadableException”。A1这很可能是因为XssHttpServletRequestWrapper中的getInputStream()方法没有处理好非JSON请求或者清洗时破坏了JSON格式比如错误地转义了双引号。检查isJsonRequest()方法逻辑并确保EscapeUtil.clean()方法不会破坏JSON的结构重点就是双引号问题。Q2文件上传Multipart接口出错了。A2对于multipart/form-data请求参数是通过getPart()或getParameter()获取的文件流是单独的。我们的包装器重写了getParameter所以表单字段会被过滤。但文件内容本身是二进制流不应该被当作字符串过滤。如果文件上传接口需要排除将其路径加入excludes列表。如果需要对文件名进行过滤可能需要更精细的处理例如在过滤器中判断Content-Type对multipart请求进行特殊解析可以使用commons-fileupload等库但这会显著增加复杂度通常建议直接排除上传接口。Q3有些合法的HTML内容比如富文本编辑器提交的被过滤掉了。A3这是白名单策略的必然结果。你需要根据业务需求扩展HTMLFilter中的白名单vAllowed。例如允许p,div,span,ul,ol,li,table,tr,td等标签以及style,class等安全的属性。务必谨慎每增加一个标签或属性都要评估其可能带来的风险比如style属性可能包含expression等危险内容。对于复杂的富文本场景可以考虑使用专业的富文本编辑器如UEditor、WangEditor配合其自带的XSS过滤规则或者使用更强大的第三方过滤库如Jsoup。Q4过滤器的顺序似乎有问题没生效。A4确保在FilterConfig中XssFilter的注册顺序setOrder被设置为较高的值数字越小优先级越高。它应该在编码过滤器如CharacterEncodingFilter之后运行因为我们需要先拿到正确编码的字符串。通常设置为Ordered.HIGHEST_PRECEDENCE 1或类似的值并通过实际调试来确定最佳顺序。7. 方案对比与总结最后我们来横向对比一下几种常见的Spring Boot防XSS方案看看我们这个“5分钟过滤器”方案的定位。方案实现复杂度维护成本性能影响防御粒度适用场景手动转义低每个点写一行代码高容易遗漏分散在各处低细粒度但依赖开发人员小型项目或无法全局改造的老系统AOP切面中中中方法级别可针对注解需要对特定方法或注解进行处理的场景自定义序列化器中高中中全局针对JSON输入输出纯JSON API项目与Jackson框架绑定本文的全局过滤器中低集中一处中全局所有请求入口绝大多数Web项目尤其是混合表单和JSON请求的MVC应用专业安全库低低视库而定全面功能强大对安全要求极高有专业运维团队的项目总结一下这个基于过滤器的XSS防御方案最大的优势在于全局性和对业务代码的零侵入。你只需要引入几个类做简单配置整个应用就获得了基础的XSS免疫能力。它可能不是功能最强大的但绝对是性价比最高、最“省心”的方案之一特别适合快速发展的业务项目。当然没有银弹。这个方案主要解决了存储型和反射型XSS的输入过滤问题。要构建真正坚固的防线必须结合输出编码、CSP、安全的Cookie策略以及持续的安全代码审计。安全是一个过程而不是一个特性。希望这个“5分钟”的实战方案能成为你SpringBoot应用安全之旅的一个可靠起点。
1. 项目概述为什么你的SpringBoot应用需要一个XSS过滤器做Web开发这些年我见过太多因为XSS跨站脚本攻击漏洞导致的“惨案”。从用户留言板里突然弹出的恶作剧弹窗到被悄无声息盗走的用户Cookie再到页面被恶意跳转到钓鱼网站这些问题的根源往往不是业务逻辑有多复杂而是开发者在处理用户输入时少了一层“净化”的工序。尤其是在SpringBoot这种快速开发框架下我们往往专注于实现业务功能却容易忽略Web安全这个基础防线。XSS攻击的原理其实不复杂简单说就是攻击者把恶意脚本代码“混”在正常的用户输入里比如评论、昵称、搜索关键词提交给服务器。如果服务器没有对这些输入进行过滤或转义就直接存储并展示给其他用户那么其他用户的浏览器就会把这些恶意脚本当作正常的页面代码来执行。这就好比你把一个陌生人递过来的、没经过安检的包裹直接放进了自己家风险可想而知。SpringBoot项目实战中集成一个全局的XSS防御机制是每个项目上线前必须完成的“规定动作”。今天要聊的就是一个能在5分钟内为你的SpringBoot应用“穿上防弹衣”的实战方案。它不依赖任何重量级的安全框架核心就是一个自定义的过滤器Filter配合一个精心编写的HTML过滤器实现对请求参数的全局清洗。我会把完整的、可运行的代码示例拆开揉碎了讲给你听从原理到避坑保证你拿过去就能用。2. XSS攻击的本质与SpringBoot的防御盲区在动手写代码之前我们必须先搞清楚敌人是谁以及我们现有的防御体系哪里最薄弱。很多开发者以为用了SpringBoot安全就高枕无忧了其实不然。2.1 XSS攻击的三种常见“姿势”XSS攻击主要分为三类反射型、存储型和DOM型。我们的防御方案需要能覆盖前两种最常见的情况。反射型XSS这种攻击像是“一次性钓鱼”。恶意脚本作为请求参数比如在URL里发送给服务器服务器未经处理就直接把参数内容嵌入了响应页面中。典型的场景是搜索框攻击者构造一个包含恶意脚本的搜索链接发给受害者受害者一点击脚本就在其浏览器中执行了。它的数据不存储在服务器端。存储型XSS这才是“心腹大患”。攻击者将恶意脚本提交到服务器比如写入数据库的论坛帖子、用户昵称当其他用户浏览到这些被“污染”的数据时脚本就会执行。它的危害是持久性的影响所有访问相关页面的用户。DOM型XSS这种攻击发生在客户端恶意脚本通过修改页面的DOM结构来实施不经过服务器端处理。防御它主要靠前端对innerHTML、document.write等危险操作的谨慎使用以及实施严格的CSP内容安全策略。我们今天的服务器端过滤器对它的直接防御有限但良好的编码习惯可以避免。2.2 SpringBoot的默认安全配置与我们的需求Spring Boot Security 确实提供了一套强大的安全框架但它更侧重于身份认证Authentication和授权Authorization比如防止未登录访问、控制页面权限。对于XSS这种“输入净化”层面的问题它并没有开箱即用的、针对请求体内容进行字符串级别过滤的全局解决方案。我们常见的做法是在每个Controller的方法参数里用RequestParam或RequestBody接收数据后手动调用工具类进行转义。这种方法有两大弊端一是容易遗漏哪个开发人员敢保证自己每次都能记得二是代码侵入性强业务代码里混杂着安全逻辑不优雅。因此我们需要一个全局的、非侵入的、对业务透明的解决方案。过滤器Filter正是Servlet规范中用于在请求到达Servlet之前和响应发出之后进行处理的组件它是实现这个需求的绝佳位置。我们的目标就是创建一个XSS过滤器在HTTP请求刚进入应用时就对所有参数进行“消毒”处理。3. 核心防御方案设计全局过滤器的实现思路整个防御体系的核心是一个自定义的XssFilter和一个包装了HttpServletRequest的XssHttpServletRequestWrapper。思路是“偷梁换柱”当请求经过我们的过滤器时我们不把原始的HttpServletRequest对象传递给后面的Controller而是传递一个被我们包装过的、重写了关键方法如getParametergetInputStream的对象。这样Controller从请求对象中获取的任何参数都已经是经过我们清洗过的“安全数据”。3.1 方案选型为什么是过滤器而不是拦截器或AOP这里可能有人会问Spring里不是还有拦截器Interceptor和面向切面编程AOP吗为什么偏偏选过滤器执行时机最早Filter是Servlet层面的组件它的执行在Spring MVC的DispatcherServlet之前。这意味着在请求进入Spring框架之前我们就能完成过滤范围最广能处理静态资源请求等。对请求体Request Body处理更友好拦截器和AOP通常作用于Controller方法被调用时此时请求参数可能已经被Spring MVC的HttpMessageConverter如处理JSON的MappingJackson2HttpMessageConverter解析成了Java对象。要修改这些对象里的数据比较麻烦。而过滤器可以在流级别直接对原始的请求体数据进行处理。更通用Filter是Java EE标准不依赖于Spring理论上更通用。虽然我们在Spring Boot里用但这个思想可以迁移。当然这个方案也有一个需要特别注意的点请求体InputStream在Servlet规范中默认只能读取一次。我们的包装器需要读取流并进行清洗那么后续的Controller或框架再读取时就会遇到流已关闭的问题。因此我们必须在包装器里把清洗后的数据缓存起来并提供一个可以重复读取的InputStream。这是实现过程中的一个关键细节。3.2 整体架构与流程整个方案的代码结构清晰主要包含以下几个部分XssFilter入口过滤器负责判断当前请求是否需要过滤比如排除一些特定的URL并将原请求对象替换为我们的包装器。XssHttpServletRequestWrapperHttpServletRequestWrapper的子类。这是核心我们通过重写getParameter、getParameterValues、getHeader、getInputStream等方法在这些方法返回数据前插入我们的清洗逻辑。EscapeUtil / HTMLFilter实际的清洗工具类。EscapeUtil提供简单的转义Escape和清理Clean方法。HTMLFilter则是一个更复杂的、可配置的HTML标签过滤器它可以根据白名单决定保留哪些安全的HTML标签和属性。FilterConfigSpring Boot配置类用于将我们自定义的XssFilter注册到Spring容器中并可以通过application.yml配置文件来灵活控制过滤器的开关、排除的URL等。流程图可以简单理解为HTTP Request-XssFilter- (如果需要过滤) 将Request对象替换为XssHttpServletRequestWrapper-Spring MVC DispatcherServlet-Controller。Controller感知不到包装过程它拿到的一切参数都是干净的。4. 代码逐行精讲与避坑指南接下来我们深入到代码内部。我会把核心代码拆解出来并附上我实际项目中踩过的坑和总结的经验。4.1 基石HTML过滤工具类HTMLFilter这个类是整个清洗逻辑的发动机。它来自开源项目OWASP Java HTML Sanitizer的思想是一个功能相对完善的白名单过滤器。代码较长但核心逻辑是使用正则表达式匹配HTML标签和属性然后根据预定义的白名单决定是保留、移除还是转义。关键配置点在无参构造函数中public HTMLFilter() { vAllowed new HashMap(); final ArrayListString a_atts new ArrayList(); a_atts.add(href); a_atts.add(target); // 允许a标签有href和target属性 vAllowed.put(a, a_atts); final ArrayListString img_atts new ArrayList(); img_atts.add(src); img_atts.add(width); img_atts.add(height); img_atts.add(alt); // 允许img标签有这些属性 vAllowed.put(img, img_atts); // 允许b, strong, i, em标签但不允许它们有任何属性空列表 final ArrayListString no_atts new ArrayList(); vAllowed.put(b, no_atts); vAllowed.put(strong, no_atts); vAllowed.put(i, no_atts); vAllowed.put(em, no_atts); vSelfClosingTags new String[] { img }; // 自闭合标签 vNeedClosingTags new String[] { a, b, strong, i, em }; // 需要闭合的标签 vAllowedProtocols new String[] { http, mailto, https }; // 链接允许的协议 // ... 其他配置 }实操心得1白名单策略比黑名单更可靠千万不要试图列一个“所有危险标签”的黑名单去过滤因为HTML和JavaScript的变形组合方式太多了比如大小写混合、嵌套无效标签、利用HTML实体编码等防不胜防。最安全的做法是采用白名单只允许已知安全的标签和属性通过。上面的配置就是一个非常保守的白名单只允许一些基本的、用于排版的标签。对于富文本编辑器如博客内容的场景你需要根据业务需求谨慎地扩充这个白名单比如增加p,span,ul,li等但一定要避免加入script,style,iframe,onclick这类高危标签或事件属性。实操心得2注意JSON数据中的双引号在HTMLFilter的encodeQuotes方法中有一段注释“不替换双引号为quot;防止json格式无效”。这是因为JSON格式严格依赖双引号来包裹属性名和字符串值。如果我们将双引号转义会导致后续的Jackson等JSON解析器报错。因此在过滤JSON请求体时这个细节至关重要。我们的清洗策略是移除或转义整个脚本标签而不是破坏JSON的结构。4.2 核心包装器XssHttpServletRequestWrapper这个类是拦截和清洗数据的关键。它继承了HttpServletRequestWrapper可以重写父类的方法。public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } Override public String[] getParameterValues(String name) { String[] values super.getParameterValues(name); if (values ! null) { String[] escapesValues new String[values.length]; for (int i 0; i values.length; i) { // 关键清洗操作清理XSS并去除前后空格 escapesValues[i] EscapeUtil.clean(values[i]).trim(); } return escapesValues; } return super.getParameterValues(name); } Override public ServletInputStream getInputStream() throws IOException { // 1. 判断是否为JSON请求 if (!isJsonRequest()) { return super.getInputStream(); // 非JSON按普通请求处理如果需要过滤普通表单可在此扩展 } // 2. 读取原始请求体 String json IOUtils.toString(super.getInputStream(), StandardCharsets.UTF_8); if (StringUtils.isEmpty(json)) { return super.getInputStream(); } // 3. 对JSON字符串进行XSS清洗 json EscapeUtil.clean(json).trim(); // 4. 将清洗后的字符串重新封装为InputStream byte[] jsonBytes json.getBytes(StandardCharsets.UTF_8); final ByteArrayInputStream bis new ByteArrayInputStream(jsonBytes); return new ServletInputStream() { // ... 实现InputStream的抽象方法基于bis操作 Override public int read() throws IOException { return bis.read(); } // ... isFinished, isReady, setReadListener 等方法 }; } // ... 同样需要重写 getParameter, getHeader 等方法 }避坑指南1请求体只能读一次这是实现中最容易出错的地方。HttpServletRequest的getInputStream()方法返回的流默认只能读取一次。在我们的getInputStream()方法里我们通过IOUtils.toString把流读完了那么后续Spring MVC框架来解析RequestBody时就会拿到一个空流。所以我们必须把清洗后的JSON字符串jsonBytes缓存到一个新的ByteArrayInputStream中并返回这个新流的包装。这样无论后面读多少次数据都还在。避坑指南2区分请求类型我们重写的getInputStream()中首先判断!isJsonRequest()。这里假设只有Content-Type为application/json的请求体需要特殊处理因为要保护JSON结构。对于传统的application/x-www-form-urlencoded表单提交其参数是通过getParameter()方法获取的已经在上面重写的方法里处理了。如果你的应用还有multipart/form-data文件上传需要额外注意文件内容本身通常不需要进行HTML清洗但文件名Filename可能需要。这部分可以根据业务情况在过滤器中排除或单独处理。4.3 入口与调度XssFilter 与 FilterConfigXssFilter是过滤器的实现它决定哪些请求需要被处理。public class XssFilter implements Filter { private ListString excludes new ArrayList(); // 排除的URL模式 Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; if (handleExcludeURL(req)) { chain.doFilter(request, response); // 直接放行 return; } // 使用包装器 XssHttpServletRequestWrapper xssRequest new XssHttpServletRequestWrapper(req); chain.doFilter(xssRequest, response); } private boolean handleExcludeURL(HttpServletRequest request) { String url request.getServletPath(); String method request.getMethod(); // 示例GET和DELETE请求不过滤根据场景决定通常GET也可能有XSS风险 if (method null || HttpMethod.GET.matches(method) || HttpMethod.DELETE.matches(method)) { return true; } // 检查是否在排除列表里 return StringUtils.matches(url, excludes); } }FilterConfig是Spring Boot的配置类用于将过滤器注入到Servlet容器。Configuration public class FilterConfig { Value(${xss.enabled:true}) private String enabled; Value(${xss.excludes:/system/notice,/api/upload}) private String excludes; Value(${xss.urlPatterns:/*}) private String urlPatterns; Bean ConditionalOnProperty(value xss.enabled, havingValue true) public FilterRegistrationBeanXssFilter xssFilterRegistration() { FilterRegistrationBeanXssFilter registration new FilterRegistrationBean(); registration.setFilter(new XssFilter()); registration.addUrlPatterns(StringUtils.split(urlPatterns, ,)); registration.setName(xssFilter); registration.setOrder(Ordered.HIGHEST_PRECEDENCE); // 设置最高优先级确保最先执行 MapString, String initParameters new HashMap(); initParameters.put(excludes, excludes); registration.setInitParameters(initParameters); return registration; } }配置经验ConditionalOnProperty这个注解非常好用它允许我们通过application.yml中的xss.enabled开关来动态启用或禁用整个过滤器。在测试环境或排查问题时可以临时关闭。Ordered.HIGHEST_PRECEDENCE将过滤器的执行顺序设为最高。这很重要要确保我们的清洗操作在其他可能修改请求的过滤器比如字符编码过滤器之后执行但在Spring Security等安全框架之前执行。顺序不对可能导致清洗失效或引发其他问题。排除列表excludes一定要留出排除接口。例如某些接受富文本HTML内容如文章发布的接口或者文件上传接口我们可能不希望进行严格的标签过滤而是交由更专门的内容审核或前端渲染库处理。对应的application.yml配置xss: enabled: true excludes: /system/notice,/api/rich-text/save # 多个路径用逗号分隔 urlPatterns: /* # 默认过滤所有请求5. 完整集成、测试与效果验证现在我们把所有零件组装起来并在一个Spring Boot项目中测试。5.1 项目结构与依赖创建一个标准的Spring Boot项目确保pom.xml中包含Web依赖。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 可选用于测试 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency将前面提到的HTMLFilter、EscapeUtil、XssHttpServletRequestWrapper、XssFilter、FilterConfig等类放入你的项目源码目录中。通常过滤器相关类放在com.yourproject.filter包下工具类放在com.yourproject.utils包下。5.2 编写测试Controller我们创建一个简单的Controller来验证过滤效果。RestController Slf4j public class TestController { // 测试1普通表单POST参数会被过滤 PostMapping(/test/form) public String testForm(RequestParam String content) { log.info(接收到的内容: {}, content); // 观察日志这里的content应该是被清洗过的例如scriptalert(1)/script会被过滤掉标签 return 处理后的内容: content; } // 测试2JSON格式POST请求体会被过滤 PostMapping(/test/json) public User testJson(RequestBody User user) { log.info(接收到的用户: {}, user); // 观察日志user对象的所有字符串字段都应该被清洗过 return user; } // 测试3被排除的接口内容原样返回 PostMapping(/system/notice) public String notice(RequestParam String htmlContent) { log.info(公告接口接收HTML: {}, htmlContent); // 这个接口在excludes列表里不会触发XSS过滤 return htmlContent; } Data // 使用Lombok注解 public static class User { private String username; private String email; private String bio; // 个人简介可能包含HTML } }5.3 使用Postman或CURL进行测试测试用例1反射型XSS攻击模拟向/test/form发送一个POST请求表单数据为contentscriptalert(xss)/script。预期结果在Controller里打印的日志和返回的响应中script和/script标签应该被移除只剩下alert(xss)这段文本。你的浏览器不会弹出警告框。测试用例2存储型XSS攻击模拟JSON向/test/json发送一个POST请求JSON体为{ username: hackerscriptalert(1)/script, email: testexample.com, bio: img srcx onerroralert(\gotcha\) / }预期结果username字段中的script标签被移除。bio字段中的img标签如果不在白名单内或者onerror属性不被允许整个标签会被移除或净化。返回的JSON对象中这些危险内容已不存在。测试用例3验证排除功能向/system/notice发送一个POST请求内容为p这是一个b加粗/b的公告/p。预期结果因为该接口在排除列表里所以内容不会被HTMLFilter处理原样到达Controller。这对于需要保存原始HTML的富文本编辑器接口是必要的。5.4 效果验证与日志分析启动你的Spring Boot应用运行上述测试。通过查看Controller中打印的日志你可以清晰地看到过滤前后的区别。例如对于测试用例1你的日志输出可能类似于接收到的内容: alert(xss)而不是接收到的内容: scriptalert(xss)/script这就证明我们的过滤器生效了恶意脚本标签已被成功剥离。6. 进阶考量与生产环境部署建议把代码跑起来只是第一步要真正用到生产环境还需要考虑更多细节。6.1 性能影响与优化字符串过滤尤其是复杂的正则表达式匹配肯定会有性能开销。我们需要将其降到最低。优化HTMLFilter原版的HTMLFilter使用了大量的正则表达式编译Pattern.compile。这些Pattern对象应该声明为static final常量在类加载时就初始化好避免每次过滤都重新编译。上面给出的代码示例已经做到了这一点。缩小过滤范围通过urlPatterns和excludes精确控制需要过滤的接口。对于只返回静态数据、无需用户输入的API可以排除。考虑缓存对于频繁出现的、相同的恶意模式可以考虑使用简单的缓存但要注意缓存污染和内存消耗。6.2 与其他安全机制的协同XSS防御不是孤立的它应该是一个纵深防御体系的一部分。输出编码我们的过滤器主要做输入过滤。但更安全的做法是输入验证输出编码。在某些场景下我们可能需要存储原始数据比如富文本那么在输出到HTML页面时必须使用正确的编码函数如Thymeleaf的th:text会自动转义th:utext则不会要慎用。对于非HTML的输出如JSON API要设置正确的Content-Type防止浏览器误解析为HTML。CSP内容安全策略在HTTP响应头中加入CSP策略是防御XSS的终极利器之一。它可以告诉浏览器只允许加载指定来源的脚本、样式等资源即使有恶意脚本被注入浏览器也不会执行。例如Content-Security-Policy: default-src self。这可以作为我们过滤器方案的有力补充。HttpOnly Cookie对于会话Cookie务必设置HttpOnly属性。这样即使网站存在XSS漏洞导致脚本被执行该脚本也无法通过document.cookie读取到Cookie信息从而防止会话劫持。6.3 常见问题排查FAQ在实际部署中你可能会遇到下面这些问题Q1过滤器导致我的JSON请求报错“HttpMessageNotReadableException”。A1这很可能是因为XssHttpServletRequestWrapper中的getInputStream()方法没有处理好非JSON请求或者清洗时破坏了JSON格式比如错误地转义了双引号。检查isJsonRequest()方法逻辑并确保EscapeUtil.clean()方法不会破坏JSON的结构重点就是双引号问题。Q2文件上传Multipart接口出错了。A2对于multipart/form-data请求参数是通过getPart()或getParameter()获取的文件流是单独的。我们的包装器重写了getParameter所以表单字段会被过滤。但文件内容本身是二进制流不应该被当作字符串过滤。如果文件上传接口需要排除将其路径加入excludes列表。如果需要对文件名进行过滤可能需要更精细的处理例如在过滤器中判断Content-Type对multipart请求进行特殊解析可以使用commons-fileupload等库但这会显著增加复杂度通常建议直接排除上传接口。Q3有些合法的HTML内容比如富文本编辑器提交的被过滤掉了。A3这是白名单策略的必然结果。你需要根据业务需求扩展HTMLFilter中的白名单vAllowed。例如允许p,div,span,ul,ol,li,table,tr,td等标签以及style,class等安全的属性。务必谨慎每增加一个标签或属性都要评估其可能带来的风险比如style属性可能包含expression等危险内容。对于复杂的富文本场景可以考虑使用专业的富文本编辑器如UEditor、WangEditor配合其自带的XSS过滤规则或者使用更强大的第三方过滤库如Jsoup。Q4过滤器的顺序似乎有问题没生效。A4确保在FilterConfig中XssFilter的注册顺序setOrder被设置为较高的值数字越小优先级越高。它应该在编码过滤器如CharacterEncodingFilter之后运行因为我们需要先拿到正确编码的字符串。通常设置为Ordered.HIGHEST_PRECEDENCE 1或类似的值并通过实际调试来确定最佳顺序。7. 方案对比与总结最后我们来横向对比一下几种常见的Spring Boot防XSS方案看看我们这个“5分钟过滤器”方案的定位。方案实现复杂度维护成本性能影响防御粒度适用场景手动转义低每个点写一行代码高容易遗漏分散在各处低细粒度但依赖开发人员小型项目或无法全局改造的老系统AOP切面中中中方法级别可针对注解需要对特定方法或注解进行处理的场景自定义序列化器中高中中全局针对JSON输入输出纯JSON API项目与Jackson框架绑定本文的全局过滤器中低集中一处中全局所有请求入口绝大多数Web项目尤其是混合表单和JSON请求的MVC应用专业安全库低低视库而定全面功能强大对安全要求极高有专业运维团队的项目总结一下这个基于过滤器的XSS防御方案最大的优势在于全局性和对业务代码的零侵入。你只需要引入几个类做简单配置整个应用就获得了基础的XSS免疫能力。它可能不是功能最强大的但绝对是性价比最高、最“省心”的方案之一特别适合快速发展的业务项目。当然没有银弹。这个方案主要解决了存储型和反射型XSS的输入过滤问题。要构建真正坚固的防线必须结合输出编码、CSP、安全的Cookie策略以及持续的安全代码审计。安全是一个过程而不是一个特性。希望这个“5分钟”的实战方案能成为你SpringBoot应用安全之旅的一个可靠起点。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
