理解预编译 SQL：防注入原理、局限性

一、预编译 SQL 是什么？核心优势有哪些？

预编译 SQL （Prepared Statement）是指先将带有占位符的 SQL 语句模板发送给数据库，数据库对其进行语法解析、编译和优化，生成执行计划并缓存，后续执行时只需将参数值传递给这个模板，而不再重新编译整条 SQL。

它的工作流程通常分为三步：

1. 准备阶段 ：发送 SQL 模板（如 SELECT * FROM user WHERE id = ?），数据库解析并编译。

2. 绑定参数 ：将具体值（如 1001）绑定到占位符 ? 上。

3. 执行：执行已编译好的语句。

核心优势：

性能提升

同一条 SQL 模板只需编译一次，后续不同参数的重复执行会直接复用执行计划，大幅减少 SQL 编译开销，尤其在高并发或批量操作场景下效应显著。

防止 SQL 注入

参数被当作"纯数据"处理，与 SQL 逻辑彻底分离。无论参数值中包含什么特殊字符（如 '、--、; 等），都不会被当作 SQL 代码执行。

代码清晰可维护

开发人员不需要手动拼接字符串和转义特殊字符，代码逻辑更直观，也降低了因拼接疏忽造成的语法错误。

---

二、什么是 SQL 注入？为什么它这么危险？

SQL 注入（SQL Injection）是一种通过将恶意的 SQL 代码插入到应用程序的输入参数中，从而欺骗数据库执行非预期查询的攻击手段，也是 Web 应用最常见、危害最大的安全漏洞之一。

经典注入场景：登录验证

后端通过字符串拼接生成 SQL：

SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"

注入示例 1：注释符绕过密码验证

攻击者在用户名输入框填写：admin' -- ，密码随意填写

最终拼接生成的 SQL：

SELECT * FROM users WHERE username = 'admin' -- ' AND password = 'anything'

-- 是 SQL 注释符，后续的密码校验逻辑被直接忽略，攻击者无需密码即可登录管理员账号。

注入示例 2：恒真条件万能绕过

攻击者用户名、密码均填写：' OR '1'='1

最终拼接生成的 SQL：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1'

'1'='1' 是恒成立条件，查询会返回所有用户数据，直接绕过登录认证。

注入的严重危害：

• 数据泄露 ：攻击者可以使用 UNION SELECT 窃取用户、订单、支付等敏感数据

• 数据破坏 ：注入 UPDATE/DELETE/DROP TABLE 语句，篡改、删除业务数据

• 服务器入侵：部分数据库可被利用执行系统命令，导致服务器被控制

• 隐蔽性强：注入攻击隐藏在正常请求中，传统防火墙难以识别

---

三、实战演示：SQL 注入 vs 预编译防护

3.1 不安全写法：字符串拼接（存在注入漏洞）

public boolean login(String username, String password) {
    // 字符串拼接SQL，高危写法
    String sql = "SELECT * FROM users WHERE username = '" + username 
               + "' AND password = '" + password + "'";
    Statement stmt = connection.createStatement();
    ResultSet rs = stmt.executeQuery(sql);
    return rs.next(); 
}

上述两种注入攻击均可轻松绕过校验。

3.2 安全写法：预编译语句（彻底防注入）

public boolean loginSafe(String username, String password) {
    // 预编译模板，使用?占位符
    String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
    PreparedStatement pstmt = connection.prepareStatement(sql);
    // 绑定参数，数据与SQL语法彻底分离
    pstmt.setString(1, username);
    pstmt.setString(2, password);
    ResultSet rs = pstmt.executeQuery();
    return rs.next();
}

此时攻击者输入 admin' -- 或 'OR'1'='1，都会被数据库当作普通字符串处理，自动转义特殊字符，注入攻击完全失效。

---

四、关键问题：预编译一定能百分百防御 SQL 注入吗？

标准答案：

对于严格参数化查询（字段值部分）可以完全防御；但如果 SQL 结构本身需要动态拼接（如表名、列名、order by 字段），无法使用预编译占位符，此时仍需结合白名单等其他手段。

通俗解读：

预编译（PreparedStatement）只能保护「数据值」部分不被注入，但无法保护「SQL 结构」部分，比如表名、列名、排序字段、分组字段等。

4.1 预编译能做什么：纯数据值防护

以条件查询为例：

SELECT id, name FROM users WHERE id = ?

数据库优先编译固定 SQL 骨架，? 仅作为参数占位符。

无论用户输入正常数字，还是恶意内容 1 OR 1=1，数据库只会将其识别为纯字符串/数值数据 ，不会解析为 SQL 逻辑代码。

✅ 结论：WHERE、IN、VALUES、SET 等数值位置，预编译绝对防注入。

4.2 预编译不能做什么：无法防护 SQL 结构

表名、列名、排序字段属于 SQL 语法中的标识符 ，语法层面不允许使用 ? 占位符，只能通过字符串拼接实现动态效果，天然存在注入风险。

场景1：动态表名（分表业务）

String tableName = "user_" + month;
String sql = "SELECT * FROM " + tableName + " WHERE id = ?";

? 只能替换查询值，不能替代表名。若 month 由用户可控，攻击者恶意传入：

202604; DROP TABLE users --

最终执行 SQL：

SELECT * FROM user_202604; DROP TABLE users -- WHERE id = ?

造成数据表被删除。

场景2：动态排序 ORDER BY

开发常需前端指定排序字段，如下错误写法完全无效：

SELECT * FROM products ORDER BY ?  

ORDER BY 后要求列名字符串（标识符），占位符会被强制解析为字符串常量，只能手动拼接字段：

String orderBy = request.getParameter("orderBy");
String sql = "SELECT * FROM products ORDER BY " + orderBy;

恶意输入：price; DELETE FROM products --，直接触发数据删除。

场景3：动态查询列名

SELECT ? FROM product WHERE id = ?

第一个占位符处于列名标识符位置，无法动态匹配字段，只会被解析为普通字符串常量，业务失效且存在注入隐患。

4.3 三大核心疑问深度拆解

疑问1： SELECT * FROM tableName + WHERE id = ?，这里的 ? 会被当成字符串吗？

不会。
? 的解析规则由语法位置 决定：

• 出现在 =、IN、AND 等条件值位置：是标准预编译占位符，单独二进制传输，不会做字符串转义；

• 带引号的 '?' 才是普通字符串，无引号的 ? 是数据库专属参数标记。

疑问2： ORDER BY ? 为什么排序失效、被当成字符串？

ORDER BY 语法要求后面必须是字段标识符 ，不能是常量值。

绑定参数后等价于：ORDER BY 'price'，全局统一常量，所有行排序一致，排序完全失效；多数数据库驱动会直接抛出异常禁止该写法。

疑问3： SELECT ? 和 WHERE id = ? 两个占位符区别

位置	SQL 片段	语法限制	最终效果
头部占位符	SELECT ?	标识符位置，禁止占位符	转为常量字符串，返回固定文本
条件占位符	WHERE id = ?	常量值位置，支持占位符	正常参数绑定，安全过滤

4.4 核心规律总结

预编译的 ? 仅能用于 SQL 允许填写常量值的位置；表名、列名、ORDER BY、GROUP BY 等结构标识符位置，占位符要么报错，要么降级为普通常量，完全无法防注入。

---

五、核心答疑：预编译 SQL 的模板是开发者自己准备的吗？

答案：是的！模板 100% 由开发者定义，绝不会被用户输入篡改！

很多同学有疑惑：原生 JDBC 要手写 ? 模板，用 MyBatis 的 #{} 时，我没写模板啊？

这是最大的误区：MyBatis 的 #{} 就是预编译模板的语法糖，你写的 XML/注解 SQL，就是在定义模板！

对比说明

1. 原生 JDBC（手动写模板）

   // 开发者手动定义预编译模板
   String sql = "SELECT * FROM user WHERE id = ?";

2. MyBatis（自动生成模板）

   <select id="getUser" resultType="User"> SELECT * FROM users WHERE id = #{id} </select>

MyBatis 自动执行转换 ：
#{id} → 替换为 ? → 生成标准预编译模板

SELECT * FROM users WHERE id = ?

完整执行流程

1. 开发者编写 MyBatis SQL（含 #{}）

2. MyBatis 解析，将 #{} 替换为 ?，生成固定模板

3. 模板发送给数据库编译、缓存

4. 执行时传入参数，安全绑定到占位符

✅ 总结：无论原生 JDBC 还是 MyBatis，预编译模板始终由开发者定义，这是防注入的核心保障。

---

六、预编译防 SQL 注入的底层原理

预编译能彻底杜绝注入的根本原因：SQL 语法结构与参数数据彻底分离。

1. 拼接 SQL 的缺陷

数据库会对完整的 SQL 字符串做词法/语法分析，用户输入的恶意字符会改变 SQL 语法树，被当作代码执行。

2. 预编译的安全机制

先发送固定模板，数据库编译后生成不可修改的执行计划；参数单独传输，仅作为纯数据填充，不会参与语法解析。

3. 物理隔离

参数通过专门的二进制协议传输，与 SQL 文本分通道传送，从根源杜绝"数据变代码"。

---

七、MyBatis 中 #{} 和 ${} 的区别

写法	机制	安全性	使用场景
#{}	预编译占位符，自动转 ?	安全，防注入	传递字段值（必用）
${}	纯字符串直接替换	不安全，有注入风险	动态表名/列名/排序

示例说明

1. #{} 安全用法

   SELECT * FROM users WHERE id = #{id}

生成：SELECT * FROM users WHERE id = ?

2. ${} 风险用法

   SELECT * FROM ${tableName} WHERE id = #{id}

若用户输入 users; DROP TABLE users; --，会直接执行删表操作。

使用规范

• 所有参数值 必须用 #{}

• ${} 仅限内部可控场景，必须配合白名单校验

• 严禁将用户输入直接传入 ${}

---

八、SQL 结构注入解决方案：白名单校验

针对动态表名、排序字段、动态列名等无法使用预编译的场景，统一使用白名单机制 拦截非法输入。${} 不是不能用，而是必须配合白名单用！

示例 1：动态排序字段白名单

String orderBy = request.getParameter("orderBy");
// 固定合法字段白名单
Set<String> allowed = Set.of("price", "create_time", "id");
if (!allowed.contains(orderBy)) {
    throw new IllegalArgumentException("非法排序字段，禁止访问");
}
String sql = "SELECT * FROM products ORDER BY " + orderBy;

示例 2：动态分表名白名单

String year = request.getParameter("year");
String table = "user_" + year;
Set<String> allowedTables = Set.of("user_2025", "user_2026");
if (!allowedTables.contains(table)) {
    throw new IllegalArgumentException("非法表名");
}

---

结语

1. 预编译 SQL 只能百分百防护数据值类 SQL 注入，无法防护表名、列名、排序等 SQL 结构注入；

2. MyBatis #{} 是预编译语法糖，底层自动转为 ? 占位符，模板由开发者定义，天然安全；

3. 两类经典注入漏洞：admin' -- 注释绕过、' OR '1'='1 恒真绕过，仅存在于字符串拼接写法；

4. 动态 SQL 结构场景，禁止直接拼接用户输入，强制使用白名单校验；

5. 开发铁律：永远不用用户输入拼接 SQL，值查询用 #{}，动态结构加白名单。