当前位置：首页 > news >正文

MyBatis-Plus apply方法避坑指南：你以为的‘灵活’可能藏着SQL注入风险

news 2026/4/24 13:25:35

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写法。