如何在MyBatis中使用$符号时通过代码逻辑手动拦截SQL注入？-SQL-PHP中文网

必须用 ${} 的地方是字段名、表名、order by 后的列名及 limit 中的偏移量表达式，因 #{} 会加引号或不支持运行时计算；白名单校验更可靠因其可防 unicode 绕过等高级注入，且须在 java 层落地；校验应通过工具类或 aop 拦截器与 mybatis 安全耦合，禁用 @select 注解中 ${}；like 场景须避免 ${}，改用 #{keyword} 拼接；批量操作和分库路由中的动态表名也需白名单校验。

如何在mybatis中使用$符号时通过代码逻辑手动拦截sql注入？

哪些地方必须用 ${} 才能跑通？

不是所有 ${} 都该删，强行全替换成 #{} 会导致语法错误。MySQL 不允许字段名、表名、ORDER BY 后的列名加引号，#{} 会自动加引号，所以这些地方必须用 ${}：

FROM ${tableName} —— #{tableName} 变成 FROM 'user_202606'，直接报错
ORDER BY ${sortField} ${sortOrder} —— #{sortField} 变成 ORDER BY 'created_time'，排序失效
LIMIT ${offset}, #{size} —— 偏移量是计算表达式，#{} 不支持运行时计算，且不能加引号

为什么白名单校验比过滤单引号更可靠？

攻击者根本不用单引号就能注入：admin' OR 1=1 -- 是入门级写法，但 admin` UNION SELECT password FROM user--、admin/*+*/OR/*+*/1=1、甚至用 Unicode 编码绕过正则，都让“删单引号”“加反斜杠”这类简单过滤形同虚设。

真正能落地的只有白名单，而且必须在 Java 层做，不能靠前端传参约定或数据库权限限制：

表名校验：用 String[] validTables = {"user", "order_v2", "log_202606"} + Arrays.asList(validTables).contains(tableName)
排序字段映射：定义 Map<string string> sortFieldMap = Map.of("ctime", "created_at", "utime", "updated_at")</string>，只接受 key，查表转真实字段
排序方向强制限定：if (!"asc".equalsIgnoreCase(sortOrder) && !"desc".equalsIgnoreCase(sortOrder)) { throw new IllegalArgumentException("sortOrder must be 'asc' or 'desc'"); }

如何把校验逻辑和 MyBatis 调用安全耦合？

别在 Service 层临时判断再传给 Mapper —— 容易漏、难复用、测试难覆盖。推荐封装成工具方法或自定义注解，在参数进入 SQL 前就卡死：

防SQL注入的php类库

下载

写一个 SafeSqlParam 工具类，暴露 checkTableName(String)、resolveSortField(String) 等静态方法，Mapper 接口调用前统一过一遍
如果用注解方式，可定义 @ValidTableName，配合 AOP 或 MyBatis Interceptor 拦截 Executor.update/Query，解析 SQL 中的 ${} 占位符并校验对应参数值
禁止在 @Select 注解里用 ${} —— 注解字符串无法被拦截器动态检查，必须收口到 XML 或 @SelectProvider 方法中，才能插入校验逻辑

容易被忽略的危险点：LIKE 场景下的 ${} 拼接

很多人以为 LIKE '%${keyword}%' 只是模糊查询，但只要用了 ${}，它就是注入高危区。哪怕 keyword 来自内部系统，一旦上游某处放开用户输入，立刻失守。

正确做法不是“加个 escape”，而是彻底避免 ${} 用于任何用户可控字段值：

改用 LIKE CONCAT('%', #{keyword}, '%')（MySQL）或 LIKE '%' || #{keyword} || '%'（PostgreSQL）
如果数据库不支持函数拼接，就在 Java 层提前加好 %：mapper.searchUsers("%" + keyword + "%")，然后 XML 中写 WHERE name LIKE #{keyword}
绝对不要写 LIKE '%${keyword}%'，哪怕你加了 ESCAPE '\' + keyword.replace("\", "\\").replace("%", "\%").replace("_", "\_") —— 这种写法仍可能被绕过，且维护成本远高于用 #{}

最常被跳过的一步：校验逻辑没覆盖到批量操作或分库路由场景。比如按租户动态选表，${tenantId}_user 这种拼接，tenantId 必须同样走白名单或长度+字符集双重校验，不能只信中间件或配置中心返回值。