ChatGPT解决MyBatis SQL注入风险指南

MyBatis 里哪些写法最容易引爆 SQL 注入？直接说结论：【${} 拼接、动态表名/列名、ORDER BY 后直接塞用户参数、@Select 硬编码加字符串拼接】，这四个是头号高危区。#{} 默认是安全的，但先别高兴太早——bind 标签或者自定义 TypeHandler 用不好，照样能绕过安全防线。

现实场景下，想在项目里快速锁定并修复潜在的注入点，总不能靠人工一行一行翻源码去猜吧？ChatGPT 能帮你定位危险写法、解释框架机制、甚至生成安全等效代码，但最终能不能落地，还得看你自己对 Mapper XML 和 Ja va 层调用关系的判断——工具只是个翻跟斗。

确认 MyBatis 中哪些写法会触发 SQL 注入

先抛给 ChatGPT 一个问题：“请列举 MyBatis 中所有可能导致 SQL 注入的写法，按风险等级排序，并说明每种写法在 XML 和注解两种场景下的具体表现。”

它一般会直接点出上边那四类高危写法。而 #{} 包裹的参数默认安全，但一旦搭配 bind 标签或者自定义 TypeHandler 用歪了，照样可能绕开保护。

注意这里有个容易踩的坑：ChatGPT 可能会把 列为“中危”——其实 bind 本身不引入注入，但如果后续在 WHERE 条件里用 ${pattern} 去引用它，那就瞬间变成高危。

让 ChatGPT 分析你自己的 Mapper XML 片段

把你有疑虑的 XML 代码块直接复制进去，提问：“这段 MyBatis XML 是否存在 SQL 注入风险？请逐行指出问题位置、攻击者可利用方式、以及安全改写建议。”

假设你提交了这么一段：


SELECT * FROM user WHERE 1=1
AND name LIKE '%${name}%'
ORDER BY ${sortField} ${sortOrder}


ChatGPT 几乎立刻会标出两处高危：${name} 导致 LIKE 注入——攻击者只要输入 a%' OR '1'='1 就能闭合单引号；而 ${sortField} 和 ${sortOrder} 完全不受控制，甚至可以嵌入 UNION SELECT 等任意语句。

它给出的建议通常是：name 改用 #{} + 在 Ja va 层拼接通配符（比如 %#{name}%），sortField / sortOrder 必须走白名单校验，绝不能由前端直传。

生成可落地的安全替换代码

方法一：简单场景，直接让 ChatGPT 输出完整安全版 XML

输入：“把上面那段 XML 改成完全防御 SQL 注入的版本，要求：name 支持模糊搜索，sortField 只允许 id/name/age 三个字段，sortOrder 只允许 asc/desc，其余非法值全部忽略。”

它会返回一段带 校验的 XML，并附上 Ja va 层需要配合的枚举定义示例。

方法二：复杂动态 SQL，让它补全 Ja va 校验逻辑

提问：“如果 sortField 来自 Controller 层 @RequestParam String sortField，怎么在 Service 里做白名单拦截？请给出 Spring Boot 风格的校验代码，含异常抛出和日志记录。”

它会写出包含 Set.of("id","name","age").contains(sortField) 判断的代码，并特别提醒：必须在 MyBatis 执行前拦截，不能依赖 XML 里的 ——很多人误以为在 XML 里加条件判断就万事大吉，其实那只是掩耳盗铃。

验证 ChatGPT 给的修复方案是否真有效

第一步：把 ChatGPT 生成的安全 XML 粘贴进 IDE，用 MyBatis-Plus 的 SQL 解析器或者手动构造恶意参数跑一遍，确认 ${} 已经完全消失。

第二步：把它的 Ja va 校验代码放进项目，启动后故意传入非法 sortField，观察是不是真的抛出 IllegalArgumentException，而不是静默忽略——静默忽略往往意味着绕过。

第三步：重点检查它没提到的边界——比如你的 DAO 方法是否用了 @SelectProvider，Provider 类里有没有自己拼 SQL；如果有，必须单独拎出来再问一次 ChatGPT。这些边角往往才是真正的雷区。

来源：互联网