MyBatis-Plus apply方法避坑指南：你以为的‘灵活’可能藏着SQL注入风险
在代码审查会上，张工突然叫停了正在演示的同事："等等，这个查询条件怎么直接把用户输入拼到SQL里了？"投影仪上的代码片段赫然写着：
wrapper.apply("username = '" + userInput + "'");会议室瞬间安静——这是典型的SQL注入漏洞。而这一切，都源于对MyBatis-Plus中apply方法的误解。
1. 危险的"灵活性"：那些年我们踩过的apply坑
去年某电商平台的用户数据泄露事件，事后排查发现漏洞竟源于一段使用apply方法拼接用户ID的查询代码。攻击者通过构造特殊输入，最终获取了管理员权限。这样的案例并非孤例，在快速开发的压力下，很多开发者会不自觉地滥用apply的"灵活性"。
1.1 错误用法典型案例
以下这些写法都暗藏杀机：
// 直接拼接用户输入（高危！） wrapper.apply("status = " + userStatus); // 字符串拼接（高危！） wrapper.apply("create_time > '" + startDate + "'"); // 看似安全的动态表名（仍然危险！） wrapper.apply("SELECT * FROM " + tableName + " WHERE id = 1");这些写法的共同问题在于：
- 直接将外部输入作为SQL语句的一部分
- 破坏了预编译机制的保护
- 为SQL注入大开方便之门
1.2 为什么参数化查询能防注入
| 查询类型 | 执行方式 | 安全性 | 性能 |
|---|---|---|---|
| 字符串拼接 | 直接执行完整SQL | 低 | 需要重复解析 |
| 参数化查询 | 先编译SQL模板再传参 | 高 | 可复用执行计划 |
参数化查询的核心在于将SQL语句与参数分离，数据库引擎会先将SQL语句编译为模板，再将参数值安全地绑定到预定位置。这个过程就像寄信时把地址和内容分开处理——即使内容中有特殊符号，也不会被误认为是地址的一部分。
2. apply方法的正确打开方式
MyBatis-Plus的apply方法设计初衷是处理那些Lambda表达式无法表示的复杂SQL片段，其安全使用的黄金法则是：永远使用{0}占位符。
2.1 安全用法示范
// 正确：使用占位符 wrapper.apply("date_format(create_time,'%Y-%m-%d') = {0}", "2023-01-01"); // 正确：多参数场景 wrapper.apply("price BETWEEN {0} AND {1}", minPrice, maxPrice); // 正确：带条件的动态SQL wrapper.apply(userId != null, "user_id = {0}", userId);这些写法会被MyBatis-Plus转换为预编译语句，例如最后一个例子会生成：
WHERE user_id = ?参数userId会被安全地传递给JDBC驱动。
2.2 特殊场景处理技巧
动态表名问题：
// 不安全写法 wrapper.apply("SELECT * FROM " + tableName); // 解决方案：使用MyBatis-Plus提供的动态表名功能 // 配置动态表名处理器复杂函数调用：
// 安全处理JSON字段查询 wrapper.apply("JSON_CONTAINS(attributes, {0})", jsonParam);3. 代码审查中的危险信号
在日常CR中，这些红色flag值得特别关注：
- 字符串拼接操作符：代码中出现
+连接SQL片段 - 未经验证的输入：用户输入直接进入apply方法
- 动态SQL构建：通过条件判断拼接SQL字符串
- 省略占位符：apply方法中看不到
{0}样式参数
一个真实的审查案例：
// 反例：根据用户选择动态排序 String orderBy = "DESC".equalsIgnoreCase(sortOrder) ? "DESC" : "ASC"; wrapper.apply("ORDER BY create_time " + orderBy);看似无害的排序参数，实际上仍存在风险。正确做法应该是：
wrapper.last("ORDER BY create_time " + orderBy); // last方法专门用于追加SQL片段4. 构建安全防线的最佳实践
4.1 防御性编程清单
- [ ] 所有动态SQL必须使用参数化查询
- [ ] 禁止任何形式的字符串拼接SQL
- [ ] 对表名、列名等元数据使用白名单校验
- [ ] 在DAO层统一封装安全查询方法
- [ ] 定期进行SQL注入专项扫描
4.2 安全工具集成
<!-- 在pom.xml中添加SQL注入检测插件 --> <plugin> <groupId>org.sonarsource.scanner.maven</groupId> <artifactId>sonar-maven-plugin</artifactId> <version>3.9.1.2184</version> </plugin>搭配SonarQube的SQL注入规则包，可以在CI流程中自动检测不安全的SQL写法。
4.3 应急响应方案
当发现生产环境存在SQL注入风险时：
- 立即回滚到安全版本
- 审查所有apply方法调用
- 更新数据库账号权限
- 监控异常查询日志
- 使用WAF临时防护
在一次内部安全演练中，我们通过日志分析发现了一个隐蔽的注入点——开发者在apply中拼接了用户搜索关键词，而攻击者可以通过精心构造的输入突破查询限制。这件事促使我们建立了更严格的代码审查机制。
记住：ORM框架不是银弹，安全编码的习惯才是终极防护。下次当你想在apply中拼接字符串时，不妨先问问自己——这个便利值得用系统安全来交换吗？
