防止SQL注入预编译SQL使用中的常见误区和规避

预编译SQL（Prepared Statement）是防止SQL注入最有效的手段之一，但很多开发者以为用了预编译就万事大吉，结果照样被注入。核心问题在于：预编译不是银弹，它只是把SQL结构和数据分离，但如果你在代码里拼了一半SQL再预编译，或者把用户输入当成表名、列名、排序字段塞进去，注入漏洞依然存在。真正安全的做法是理解预编译的边界，知道哪些地方能用参数化，哪些地方必须白名单校验，以及如何在ORM框架中避免踩坑。

一、预编译SQL防注入的核心原理到底是什么

预编译的本质是在SQL执行之前，先把SQL语句的结构发送给数据库引擎进行编译和优化，生成执行计划。用户输入的数据不再作为SQL语法的一部分被解析，而是作为纯粹的参数值绑定进去。数据库引擎在执行时，会把参数当成"数据"而非"代码"来处理，攻击者就算输入 "' OR '1'='1" 这种经典注入语句，数据库也只会把它当成一个普通字符串去比对，不会改变SQL的逻辑结构。

用Java的JDBC举个例子，正确的预编译写法是这样的：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, username);
ps.setString(2, password);
ResultSet rs = ps.executeQuery();

这里 "?" 是占位符，用户输入通过 "setString" 方法绑定，永远不会被当作SQL语法解析。这就是预编译防注入的根基。

二、最常见的误区：把拼接当成预编译

这是最高频的错误。很多开发者写的代码看起来像预编译，实际上是拼接。比如下面这段：

String sql = "SELECT * FROM users WHERE username = '" + username + "'";
PreparedStatement ps = connection.prepareStatement(sql);
ps.executeQuery();

表面上用了 "PreparedStatement"，但SQL语句本身已经在Java层面拼好了，用户输入直接嵌入到SQL字符串里。这时候预编译没有任何意义，因为SQL结构在传给数据库之前就已经被用户输入污染了。数据库拿到的是一条完整的、已经被篡改过的SQL语句，注入照样成功。

规避方法很简单：永远不要用字符串拼接来构造SQL，所有用户输入必须通过占位符 "?" 或者命名参数 ":param" 来绑定。如果你发现自己在写 "+ username +" 这种代码，立刻停下来重构。

三、动态表名和列名不能用预编译参数

预编译参数只能用于值（value），不能用于标识符（identifier）。也就是说，表名、列名、排序方向这些东西，不能用 "?" 占位符来替代。比如你想让用户选择按哪个字段排序：

String sql = "SELECT * FROM users ORDER BY ? DESC";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, sortColumn); // 这不会按你期望的方式工作

这样写的结果是数据库会把 "sortColumn" 的值当成一个字符串常量，而不是列名。最终SQL变成了 "ORDER BY 'username' DESC"，排序完全失效，而且某些数据库会直接报错。

正确的做法是用白名单校验。在代码里维护一个允许的列名列表，用户输入必须在这个列表里才能使用：

List<String> allowedColumns = Arrays.asList("username", "email", "created_at");
if (!allowedColumns.contains(sortColumn)) {
    throw new IllegalArgumentException("Invalid sort column");
}
String sql = "SELECT * FROM users ORDER BY " + sortColumn + " DESC";
Statement stmt = connection.createStatement();
stmt.executeQuery(sql);

这里虽然又出现了拼接，但因为 "sortColumn" 已经过白名单严格校验，不可能包含恶意内容，所以是安全的。关键原则：标识符用白名单，值用预编译参数，两者不能混用。

四、ORM框架中的预编译陷阱

用MyBatis、Hibernate、JPA这些ORM框架的开发者更容易掉坑。框架帮你做了很多封装，但封装不等于安全。以MyBatis为例，它有两种参数写法："#{}" 和 "${}"。

"#{}" 是预编译参数，安全。"${}" 是字符串直接替换，不安全。很多人图方便写成：

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

这和JDBC里的字符串拼接是一回事，注入风险极高。正确写法：

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

Hibernate的HQL/JPQL也有类似问题。用 "setParameter()" 是安全的，用字符串拼接是危险的。另外，Hibernate的Criteria API虽然底层会自动处理参数化，但如果你用了 "Restrictions.sqlRestriction()" 并手动拼接SQL片段，同样会引入注入风险。

五、批量操作和IN子句的常见错误

处理 "IN" 子句时，很多开发者不知道怎么动态传入多个值。有人会这样写：

String sql = "SELECT * FROM users WHERE id IN (" + idList + ")";
PreparedStatement ps = connection.prepareStatement(sql);

这里 "idList" 是一个拼接好的字符串，比如 ""1, 2, 3""，本质还是拼接。正确的做法是动态生成对应数量的占位符：

String placeholders = String.join(",", Collections.nCopies(idList.size(), "?"));
String sql = "SELECT * FROM users WHERE id IN (" + placeholders + ")";
PreparedStatement ps = connection.prepareStatement(sql);
for (int i = 0; i < idList.size(); i++) {
    ps.setInt(i + 1, idList.get(i));
}

这样每个ID都是独立的参数绑定，完全安全。如果ID数量很大（比如超过1000个），需要考虑分批查询或者用临时表方案，但参数化的原则不变。

六、存储过程调用中的参数绑定问题

调用存储过程时，如果用 "CallableStatement"，同样需要注意参数绑定方式。错误写法：

String sql = "{call sp_get_user('" + username + "')}";
CallableStatement cs = connection.prepareCall(sql);

正确写法：

String sql = "{call sp_get_user(?)}";
CallableStatement cs = connection.prepareCall(sql);
cs.setString(1, username);

存储过程内部如果有动态SQL拼接，那是数据库端的问题，需要DBA在存储过程里也做好参数化处理。应用层能做的就是确保传入存储过程的参数都是通过绑定方式传递的。

七、LIKE模糊查询的通配符处理

模糊查询是另一个容易出错的场景。用户输入 "%admin%" 想搜索包含admin的记录，如果直接绑定：

String sql = "SELECT * FROM users WHERE username LIKE ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, userInput); // userInput = "%admin%"

这样写功能上没问题，但如果用户输入的是 "%" 或者 "%' OR '1'='1%"，虽然不会造成注入（因为是参数化的），但会导致全表扫描或者返回大量无关数据，造成性能问题和信息泄露。更安全的做法是在应用层对通配符进行转义或者限制：

String safeInput = userInput.replace("%", "\\%").replace("_", "\\_");
String sql = "SELECT * FROM users WHERE username LIKE ? ESCAPE '\\'";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, safeInput);

这样既保持了预编译的安全性，又避免了通配符滥用带来的风险。

八、框架自动转义不等于安全

有些开发者依赖框架的"自动转义"功能，认为框架会帮你处理所有危险字符。但自动转义和预编译是两回事。转义只是对特殊字符做了处理，而预编译是从根本上分离了代码和数据。在某些边缘场景下，转义可能被绕过，比如字符编码问题、二次解码等。所以不要把自动转义当作防注入的唯一手段，预编译参数化才是正解。

九、二次注入和存储型注入的特殊情况

预编译能防住大部分注入，但有一种情况需要额外注意：二次注入。如果用户输入的数据先被存储到数据库（这时候是安全的，因为存储时用了预编译），但后来从数据库取出来又被拼接到新的SQL里执行，这时候就危险了。比如：

// 第一次：安全存储
String sql = "INSERT INTO config (key, value) VALUES (?, ?)";
ps.setString(1, key);
ps.setString(2, value);

// 第二次：危险读取后拼接
String raw = getFromDB(key); // 从数据库取出原始值
String sql2 = "SELECT * FROM users WHERE role = '" + raw + "'"; // 危险！

规避方法：从数据库取出的数据如果要用于构造SQL，同样必须走参数化，不能因为"数据来自数据库"就放松警惕。数据库里的数据可能已经被篡改过，或者在存储之前就被污染了。

十、总结：建立完整的防御体系

防止SQL注入不能只靠预编译这一招，需要建立多层防御。第一层，所有用户输入必须参数化绑定，杜绝任何形式的字符串拼接。第二层，动态标识符（表名、列名、排序字段）必须白名单校验。第三层，对输入数据做类型和长度校验，比如ID必须是整数，邮箱必须符合格式。第四层，使用最小权限原则，数据库连接账号只给必要的权限，不要用root账号跑业务。第五层，定期做代码审计和安全扫描，用工具检测潜在的注入点。

预编译是防SQL注入的基石，但它不是万能的。理解它的工作原理和适用边界，避开常见误区，才能真正把注入风险降到最低。安全是一个系统工程，每一层都不能偷懒。

防止SQL注入预编译SQL使用中的常见误区和规避

服务指南

帮助中心