MyBatis 如何防止 SQL 注入？

一句话总结

MyBatis 防 SQL 注入的核心是：参数一律使用 #{} 做"参数绑定"（PreparedStatement 的 ? 占位） ，让"SQL 结构"和"数据"彻底分离；对不得不用 ${} 的 表名/列名/排序 等 SQL 片段，必须做 白名单 或用 <choose> 枚举替代；同时配合代码规范、审计与测试实现多层防护。

1. 先搞清楚：SQL 注入的本质是什么？

SQL 注入并不是"没转义"，而是：把用户输入拼进 SQL 语法结构里，导致输入从"数据"变成"指令"。

因此最可靠的防护手段是：

参数绑定（PreparedStatement）：输入永远作为参数值传递，不参与 SQL 语法解析。

2. MyBatis 两种替换方式：`#{}` vs `${}`（核心）

写法	本质	是否安全	适用场景
`#{param}`	生成 `?` 占位符 + JDBC 参数绑定（TypeHandler）	安全	WHERE/INSERT/UPDATE 的"值"
`${param}`	文本原样拼接到 SQL（字符串替换）	高风险	表名/列名/ORDER BY 等"SQL 片段"

结论：

能用 #{} 就绝不用 ${}。
${} 只在"无法用 ? 占位"的场景出现，并且必须白名单。

3. 正确用法 1：所有"值"都用 `#{}`（参数绑定）

3.1 基本示例

xml 复制代码

<select id="findByName" resultType="User">
  SELECT * FROM user WHERE name = #{name}
</select>

SQL 形态：

sql 复制代码

SELECT * FROM user WHERE name = ?

此时即使输入是 admin' OR '1'='1，也只会作为一个字符串值去匹配，不会改变 SQL 结构。

3.2 关键点补充：TypeHandler / JDBC 类型处理

#{} 会走 MyBatis 的 TypeHandler，由它决定用 setString/setInt/... 绑定参数。

这不是简单"字符串转义"，而是参数绑定。
防注入的关键在于"结构与数据分离"。

4. 正确用法 2：动态 SQL 标签是安全的（前提是内部仍用 `#{}`）

MyBatis 的动态 SQL（<if> / <where> / <trim> / <choose>）只是动态组装 SQL 结构，并不等于把用户输入拼进 SQL。

只要条件值仍用 #{}，就是安全的：

xml 复制代码

<select id="query" resultType="User">
  SELECT * FROM user
  <where>
    <if test="name != null and name != ''">
      AND name = #{name}
    </if>
    <if test="age != null">
      AND age = #{age}
    </if>
  </where>
</select>

5. 常见攻击面与正确写法

5.1 `LIKE` 模糊查询

5.2 `IN` 查询（批量参数）

使用 <foreach> 生成多个 #{}：

xml 复制代码

<select id="selectByIds" resultType="User">
  SELECT * FROM user
  WHERE id IN
  <foreach collection="ids" item="id" open="(" separator="," close=")">
    #{id}
  </foreach>
</select>

不要把整段 ids 字符串塞进 ${}。

风险/后果：

如果把用户输入的 ids 直接拼成 IN (${ids})，攻击者可构造如 1) OR 1=1 --，最终 SQL 可能变为：
WHERE id IN (1) OR 1=1 --)

从而导致 IN 条件被绕过、返回全表数据，甚至在支持多语句的配置下进一步造成更严重的破坏。

5.3 分页参数

分页参数也属于"值"，用 #{}：

xml 复制代码

SELECT * FROM user LIMIT #{offset}, #{pageSize}

6. 不得不用 `${}` 的场景：必须白名单/枚举替代

6.1 为什么这些场景不能用 `#{}`？

JDBC 的 ? 占位符只能替换值，不能替换：

表名、列名
ORDER BY 的字段
ASC/DESC 关键字

因此这些场景可能出现 ${}。

6.2 推荐做法：用 `<choose>` 枚举排序字段（避免透传 `${sortField}`）

xml 复制代码

<select id="findUsers" resultType="User">
  SELECT * FROM user
  <choose>
    <when test="sortField == 'age'">ORDER BY age</when>
    <when test="sortField == 'name'">ORDER BY name</when>
    <otherwise>ORDER BY id</otherwise>
  </choose>
  <choose>
    <when test="sortOrder == 'DESC'">DESC</when>
    <otherwise>ASC</otherwise>
  </choose>
</select>

6.3 业务侧白名单映射（如果必须用 `${}`）

输入只允许来自固定集合（枚举/Map 映射），严禁直接使用用户原始字符串。
对排序字段、表名、列名做正向校验（white list），不要做"黑名单过滤"。

7. 常见误区（纠错点）

误区：#{} 是"自动转义"所以安全
- 更准确：#{} 是 参数绑定（结构与数据分离），不是靠转义。
误区：动态 SQL 一定安全
- 动态标签本身安全，但如果你在标签里用 ${} 拼接用户输入，一样会注入。
误区：把 '${name}' 包上引号就安全
- 仍是拼接，依然可能被构造输入突破。

8. 多层防护（生产建议）

仅靠 ORM 习惯不够，建议组合：

编码规范 ：禁止 ${} 透传用户输入；代码评审强制检查
参数校验：对排序字段、表名等做枚举/白名单校验
审计与测试 ：单测/集成测试加入注入 payload（如 "' OR '1'='1"）
最小权限：DB 账号权限最小化（禁止高危权限）
可选：WAF/SQL 防火墙/数据库审计（兜底）

9. 面试速答

Q：MyBatis 如何防 SQL 注入？
- A：对值使用 #{} 走 PreparedStatement 参数绑定；对必须拼接的 SQL 片段（表名/列名/排序）使用白名单或 <choose> 枚举，禁止 ${} 透传用户输入。
Q：${} 为什么危险？
- A：它是文本替换，输入会进入 SQL 结构，可能变成指令。
Q：IN / LIKE 怎么写才安全？
- A：IN 用 <foreach> + #{}；LIKE 用 CONCAT('%', #{x}, '%')。

MyBatis 如何防止 SQL 注入？