Java Web应用中怎样利用过滤器防御SQL注入？

Filter不应修改参数值，只应检测、记录、告警；必须覆盖所有输入源（JSON、multipart、Path Variable、Header、Query String）；优先白名单校验，正则匹配需加单词边界；配置外置、加载顺序正确、日志脱敏。

过滤器不能替代参数化查询，它只是一道辅助防线，且极易误拦正常请求——真要防注入，必须从 PreparedStatement 或 MyBatis 的 #{} 开始。

为什么 Filter 不该做转义或修改参数值

很多团队一上来就写 HttpServletRequestWrapper 重写 getParameter()，把 ' 换成 ''、; 直接删掉。这会导致三类问题：

• JSON 字段含 {"type": "SELECT"} 被截断，后端解析失败
• 用户昵称 O'Reilly 变成 OReilly，前端显示异常
• Servlet 容器可能缓存原始参数，getInputStream() 和 getParameterMap() 返回不一致

真正安全的做法是：Filter 只检测、只记录、只告警，绝不修改原始请求数据。

Filter 必须覆盖全输入源，不能只扫 getParameterMap()

POST JSON、PUT Body、multipart/form-data 文件上传字段、Path Variable、Header 里的 token —— 这些都不会出现在 getParameterMap() 中。只扫表单参数等于裸奔。

立即学习“Java免费学习笔记（深入）”；

• 对 application/json：用 request.getInputStream() 读原始 body，再用 Jackson/Gson 解析后遍历所有字符串字段
• 对 multipart/form-data：调用 request.getParts()，逐个检查 Part 的内容类型和字符串值
• 对 PathVariable：Spring Boot 的 @PathVariable 值在 Filter 阶段不可见，需改用 HandlerInterceptor 或提前在路由层提取（但不推荐）
• 别漏掉 GET 请求的 query string，它和 form 表单一样走 getParameterMap()

正则匹配关键字是高危操作，优先用白名单 + 日志告警

用 str.contains("union") || str.contains("select") 这类规则，会把搜索接口 /api/docs?q=select * from users 当成攻击干掉；注释里的 /* SELECT FROM */ 又会被忽略。

• 若必须匹配，用 Pattern.compile("(?i)b(select|insert|delete|update|exec|declare)b", Pattern.UNICODE_CASE)，加单词边界和大小写不敏感
• 匹配到后不要直接 response.sendError(403)，而是记录日志 + 设置标记，让后续 HandlerInterceptor 或全局异常处理器决定是否拦截
• 更稳妥的方式是：只对已知高危上下文做白名单，比如排序字段只允许 ["id", "created_at", "status"]，其余一律拒绝
• 配置项必须外置，如 @Value("${security.sql-filter.enabled:true}")，上线前可快速关闭避免误伤

Filter 加载顺序和路径范围常被忽略

写了 @WebFilter(urlPatterns = "/*") 就以为万事大吉？错。Spring Boot 内嵌 Tomcat 默认不扫描非 @Component 的 Filter 类，且 SecurityFilterChain 会抢在你的 Filter 前处理未认证请求。

• 必须加 @Component，否则 @WebFilter 注解无效
• 用 @Order(Ordered.HIGHEST_PRECEDENCE) 确保它排在 Spring Security 之前
• urlPatterns 要排除健康检查、静态资源、Swagger：@WebFilter(urlPatterns = "/api/*", excludePatterns = {"/actuator/**", "/css/**", "/v3/api-docs/**"})
• 日志里别打完整参数值，尤其含 password、token、id_card 的字段，否则引入新泄露点

最麻烦的不是写一个能“拦住 or 1=1”的 Filter，而是确认它在 multipart/form-data、application/json、带文件上传的 PUT 请求里，都真的生效了——而这一点，90% 的团队上线后才发现没测全。