JSON入参的SQL注入无法用HandlerInterceptor拦截，因其执行时请求体已被解析为Java对象，原始JSON已丢失；必须用Filter结合HttpServletRequestWrapper缓存并解析body，对高风险字段白名单校验；MyBatis中${}动态SQL仍是最大漏洞点，须严格限制来源。
JSON入参引发的SQL注入，HandlerInterceptor根本拦不住——它连原始body都拿不到，必须用Filter在Servlet入口统一处理。
为什么@RequestBody参数不能靠拦截器过滤
Spring MVC的HandlerInterceptor.preHandle()执行时，请求体已被HttpMessageConverter（如Jackson2ObjectMapper）解析成Java对象，原始JSON字符串早已丢失。此时再想扫描"select"或"union"关键词，等于在炒熟的菜里找生米。
-
@RequestBody绑定后，参数是反序列化后的String、Integer等类型，不是原始JSON文本 - 攻击载荷可能藏在嵌套对象、数组元素、甚至base64编码字段里，拦截器无法还原上下文
- 若DTO里有
Map<string object></string>或JsonNode，更没法静态判断哪些字段会拼进SQL
Filter中如何安全读取并清洗JSON body
必须用HttpServletRequestWrapper重写getInputStream()和getReader()，把原始body缓存下来，再做结构化解析和校验。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 不要用
request.getReader().lines().collect(Collectors.joining())——会消耗流，后续Controller读不到数据 - 推荐做法：在
doFilter()开头用IOUtils.toString(request.getInputStream(), StandardCharsets.UTF_8)读一次并缓存，再构造CustomRequestWrapper返回该字符串 - 对JSON做轻量解析：
JsonNode root = objectMapper.readTree(jsonString)，递归遍历所有TEXT类型节点，对高风险字段（如searchKeyword、orderBy）做白名单或转义 - 避免全局正则扫描：
"(select|union|drop)\b"会误杀"user_select"这种合法字段名，优先走字段级策略
MyBatis里${}动态SQL仍是最大漏洞点
即使JSON body被Filter清洗干净，DAO层一个${sortField}就能让所有前端防护失效——因为这是SQL拼接，不是参数绑定。
-
#{}是安全的，MyBatis底层走PreparedStatement，传进去的"id; DROP TABLE users--"会被当作文本字面量 -
${}是危险的，它直接字符串替换，Filter放过的payload会在SQL生成阶段注入 - 真要动态表名或order by字段，必须硬编码白名单：
if (!List.of("id", "name", "created_time").contains(sortField)) { throw new IllegalArgumentException(); } - 禁用
@Select("SELECT * FROM ${tableName}")这类写法，改用TableNameProvider或@SelectProvider配合校验逻辑
真正难防的不是明面上的' OR 1=1 --，而是业务代码里那些“只在特定条件下拼SQL”的分支路径——它们往往绕过所有Filter和校验，直通数据库。每次加${}前，得问自己：这个字段的值，是否100%来自枚举或配置，而非用户输入？
