最有效防线是统一用#{}替代${}并严格白名单校验动态SQL。${}导致SQL注入，#{}经PreparedStatement预编译；order by等需白名单控制字段，like模糊查询须用CONCAT('%',#{keyword},'%')；全局过滤器仅作兜底，JdbcTemplate必须用参数化调用。
直接用 #{} 代替 ${} 是最有效防线
MyBatis 中 ${} 是字符串拼接，#{} 才是预编译占位符。只要用了 ${}，哪怕只在一个 order by 或 like 场景里，就等于主动打开注入入口。
常见错误写法：
<select id="listUsers" resultType="User">
SELECT * FROM user WHERE status = '${status}' ORDER BY ${sortField} ${sortOrder}
</select>正确写法（status 用 #{}，排序字段需白名单校验）：
<select id="listUsers" resultType="User">
SELECT * FROM user WHERE status = #{status} ORDER BY
<choose>
<when test="sortField == 'name'">name</when>
<when test="sortField == 'created_time'">created_time</when>
<otherwise>id</otherwise>
</choose>
<choose>
<when test="sortOrder == 'desc'">DESC</when>
<otherwise>ASC</otherwise>
</choose>
</select>-
#{}会交由 JDBC PreparedStatement 处理，数据库引擎不解析参数内容 -
${}在 XML 解析阶段就被替换成原始字符串，后续完全不受框架控制 - 模糊查询
like必须写成WHERE name LIKE CONCAT('%', #{keyword}, '%')，而不是LIKE '%${keyword}%'
全局过滤器拦截非法字符，但不能替代参数化
过滤器只能作为兜底手段，不是第一道防线。它对已知关键字（如 '、or、union、select）做粗筛，但容易被绕过（比如用大小写混写、URL 编码、注释符分隔），且无法覆盖所有上下文。
典型实现是继承 HttpServletRequestWrapper 并重写 getParameter 方法：
public class SqlInjectHttpServletRequestWrapper extends HttpServletRequestWrapper {
@Override
public String getParameter(String name) {
String value = super.getParameter(name);
if (value != null) {
return sqlFilter(value); // 正则匹配敏感词并抛异常或替换
}
return value;
}
}- 正则建议用
Pattern.compile("(?i)(\b(select|insert|update|delete|drop|exec|count|chr|mid|master|truncate|char|declare)\b|;|--|/\*|\*/|'|")") - 不要只过滤 GET/POST 参数，
getHeader和getInputStream（如 JSON body）也得处理 - 过滤后返回空字符串或抛
IllegalArgumentException，别默默替换为安全值——掩盖问题比报错更危险
JdbcTemplate 必须用 PreparedStatement 形式调用
JdbcTemplate 本身不防注入，关键看你怎么用。传入拼接好的 SQL 字符串 + 参数数组（query(String sql, Object[] args, ...)）才是安全的；而用 query(String sql, ...) 直接传完整 SQL 就是高危操作。
错误示例：
String sql = "SELECT * FROM user WHERE username = '" + username + "'"; jdbcTemplate.query(sql, ...); // ❌ 拼接即注入
正确示例：
String sql = "SELECT * FROM user WHERE username = ?";
jdbcTemplate.query(sql, new Object[]{username}, ...); // ✅ 预编译执行- 即使参数来自内部逻辑（非用户输入），也应统一走参数化，避免未来扩展时误引入风险
-
in条件要用NamedParameterJdbcTemplate配合Map，或动态生成占位符："id IN (" + String.join(",", Collections.nCopies(ids.size(), "?")) + ")" - 别信“我这个字段只存数字”，类型校验和参数化必须同时存在——攻击者可能伪造请求头或绕过前端校验
@ParmSqlInjection 自定义注解仅适合简单字段校验
这种基于关键词黑名单的注解，适合对 DTO 中明确标记的字段做轻量级扫描（如 username、email），但无法应对嵌套对象、JSON 字段、或需要上下文判断的场景（比如一个字段在 A 接口是普通文本，在 B 接口却用于 ORDER BY）。
校验器里用 String.contains() 匹配 'and exec insert select... 是明显缺陷：它会把 hand、band 这类正常词误杀，且对 se/**/lect 这种绕过毫无抵抗力。
- 若真要用，正则应至少支持忽略空格、注释、大小写：
Pattern.compile("(?is)\b(select|union|exec|xp_cmdshell)\b") - 注解应配合
@Valid在 Controller 层触发，不能只加在 VO 类上就以为万事大吉 - 它和全局过滤器一样，是“辅助线”，不是“主干道”——主干道永远是参数化查询 + 输入类型强约束
真正难防的从来不是 ' or 1=1 -- 这种显性攻击，而是业务逻辑中那些看似无害的动态表名、列名、排序字段，或者前端传来的 JSON 里嵌套的 SQL 片段。这些地方没法用 #{}，也没法靠关键词过滤穷举，必须靠设计阶段就明确白名单、拒绝运行时拼接、并在代码评审中重点盯防。
