防止SQL注入预编译语句避坑指南

预编译语句（Prepared Statement）被普遍认为是防御SQL注入最有效的手段之一，但很多开发者在使用时仍然踩坑，原因不在于预编译本身失效，而在于错误的使用方式让预编译机制被绕过或部分失效。最常见的误区是把用户输入直接拼进SQL字符串后再交给预编译对象执行，这种情况下预编译根本无法识别哪些部分是参数，注入依然畅通无阻。另一个高频问题是动态表名、列名、排序字段以及IN子句的处理，这些场景无法直接使用占位符，很多团队为了省事退回字符串拼接，结果重新打开了注入大门。下面直接拆解这些具体问题以及对应的正确处理方案。

预编译防注入的核心原理

预编译语句之所以能防注入，是因为它将SQL语句的结构与数据分离。数据库先接收SQL模板，对模板进行解析、编译和优化，生成执行计划，然后再接收参数值并执行。参数值在传递过程中不会被当作SQL代码的一部分解析，无论参数里包含什么内容，数据库都只把它当作普通数据处理。以MySQL为例，使用PDO或MySQLi的预编译语句时，客户端发送COM_STMT_PREPARE命令准备语句，再通过COM_STMT_EXECUTE命令传入参数，参数与SQL结构在协议层面就是分开的。这意味着像' OR '1'='1这样的注入载荷，在参数位置只会被当作字符串值，不会改变SQL逻辑。

错误用法一：先拼接再预编译

这是最典型的误用。看下面这段代码：

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

这段代码虽然创建了PreparedStatement对象，但SQL语句在传入prepareStatement之前已经完成了字符串拼接。username变量中的单引号会提前闭合字符串，攻击者可以构造任意SQL语句执行。预编译机制完全无法感知哪些内容来自用户输入，因为它拿到的已经是一个被污染过的完整SQL。正确做法是使用占位符：

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

这里的问号就是占位符，username的值通过setString方法绑定，数据库在编译SQL模板时知道这里是一个参数位置，后续传入的值不会被解析为SQL代码。判断标准很简单：如果你在代码中看到字符串拼接操作发生在prepareStatement调用之前，并且拼接内容包含任何外部输入，那就是不安全的。

错误用法二：动态表名和列名直接拼接

预编译语句的占位符只能用于值的位置，不能用于表名、列名、SQL关键字等标识符。很多业务场景需要动态指定排序字段、筛选字段或者动态选择表，例如后台管理系统的可配置列表。如果直接拼接：

String sql = "SELECT id, username, email FROM users ORDER BY " + orderBy + " " + sortDirection;
PreparedStatement ps = connection.prepareStatement(sql);

orderBy和sortDirection如果来自前端请求参数，攻击者可以传入类似"id; DROP TABLE users--"或者使用UNION查询窃取数据。预编译对此无能为力，因为标识符本身就无法参数化。正确的处理方式是建立白名单映射。前端传过来的字段名和排序方向必须经过严格校验，只允许预定义集合中的值：

private static final Set ALLOWED_COLUMNS = Set.of("id", "username", "email", "create_time");
private static final Set ALLOWED_DIRECTIONS = Set.of("ASC", "DESC");

public List getUsersByOrder(String orderBy, String sortDirection) {
    if (orderBy == null || !ALLOWED_COLUMNS.contains(orderBy)) {
        throw new IllegalArgumentException("Invalid column: " + orderBy);
    }
    if (sortDirection == null || !ALLOWED_DIRECTIONS.contains(sortDirection.toUpperCase())) {
        throw new IllegalArgumentException("Invalid direction: " + sortDirection);
    }
    String sql = "SELECT id, username, email FROM users ORDER BY " + orderBy + " " + sortDirection.toUpperCase();
    // 此时orderBy和sortDirection已经过白名单校验，可以安全拼接
    PreparedStatement ps = connection.prepareStatement(sql);
    return executeQuery(ps);
}

白名单校验是处理动态标识符的唯一可靠方式。不要尝试通过黑名单过滤关键字，因为SQL语法复杂，绕过方式太多。也不要用转义来处理标识符，因为不同数据库对标识符的引用规则不同，而且转义并不能覆盖所有注入场景。

错误用法三：IN子句参数处理不当

IN子句需要传入多个值，很多开发者发现占位符数量不确定，于是采用字符串拼接的方式构造IN列表：

String ids = String.join(",", requestIds); // requestIds来自用户输入
String sql = "SELECT * FROM products WHERE category_id IN (" + ids + ")";

如果requestIds中的元素是数字，攻击者可以传入"1) OR 1=1 --"这样的内容，导致注入。即使元素是字符串类型，拼接同样危险。正确做法是根据集合大小动态生成占位符：

List ids = getIdsFromRequest(); // 假设已经过类型转换
if (ids == null || ids.isEmpty()) {
    return Collections.emptyList();
}
String placeholders = String.join(",", Collections.nCopies(ids.size(), "?"));
String sql = "SELECT * FROM products WHERE category_id IN (" + placeholders + ")";
PreparedStatement ps = connection.prepareStatement(sql);
for (int i = 0; i < ids.size(); i++) {
    ps.setInt(i + 1, ids.get(i));
}
ResultSet rs = ps.executeQuery();

占位符的数量是动态生成的，但每个占位符本身都是安全的参数位置。ids集合中的每个值都通过setInt方法绑定，数据库不会把它们当作SQL代码解析。如果ids数量非常大，需要考虑分批查询或者改用临时表关联，但核心原则不变：值永远通过参数绑定传递。

错误用法四：LIKE模糊查询中的特殊字符

LIKE查询中，百分号%和下划线_是通配符，用户输入中如果包含这些字符，可能导致查询结果不符合预期，但这本身不是SQL注入问题。真正的问题在于很多开发者为了在LIKE中使用通配符，会在拼接SQL时把用户输入和%拼接在一起：

String keyword = request.getParameter("keyword");
String sql = "SELECT * FROM articles WHERE title LIKE '%" + keyword + "%'";

这是典型的拼接注入风险。正确的预编译写法是：

String keyword = request.getParameter("keyword");
String sql = "SELECT * FROM articles WHERE title LIKE ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, "%" + keyword + "%");
ResultSet rs = ps.executeQuery();

百分号在参数值中拼接，而不是在SQL字符串中拼接。这样keyword中的任何内容都只是参数值的一部分，不会破坏SQL结构。如果业务上需要让用户输入的通配符生效，可以保留用户输入的%和_，如果不需要，则需要对这两个字符进行转义，但转义操作应该在参数绑定之后由数据库函数处理，而不是在拼接阶段手动处理。

错误用法五：预编译语句重用时的参数清理

预编译语句对象可以重用，这在批量操作时能提升性能。但重用时要确保每次执行前正确设置所有参数，避免残留上一次的参数值。虽然这不直接导致SQL注入，但可能造成数据泄露或逻辑错误。例如：

PreparedStatement ps = connection.prepareStatement("SELECT * FROM users WHERE username = ? AND role = ?");
ps.setString(1, username);
// 忘记设置第二个参数role
ResultSet rs = ps.executeQuery();

如果这个PreparedStatement对象之前设置过role参数，第二次执行时role会沿用旧值，导致查询结果错误。更严重的是，如果攻击者能够控制执行流程，可能利用参数残留获取未授权数据。正确做法是每次执行前使用clearParameters方法清理参数，或者为每次执行创建新的PreparedStatement对象。在批量处理场景中，如果使用addBatch和executeBatch，也要注意在循环中正确设置每个参数。

错误用法六：ORM框架中的原生SQL拼接

现代ORM框架如Hibernate、MyBatis、JPA等，在大多数情况下会自动使用预编译语句。但很多项目在复杂查询时会使用原生SQL或动态SQL，这时候如果框架的配置不当或者开发者手动拼接，预编译保护就会失效。以MyBatis为例，使用#{}占位符时框架会生成预编译参数，而使用${}时则是直接字符串替换：

${}会直接把参数值拼进SQL字符串，等同于手动拼接，存在注入风险。除非是动态表名、列名等必须使用${}的场景，并且已经做了严格的白名单校验，否则一律使用#{}。JPA的@Query注解中，使用命名参数:paramName是安全的，但使用SpEL表达式或者字符串拼接同样危险。ORM框架并不能完全屏蔽SQL注入，开发者仍然需要理解底层机制。

错误用法七：存储过程调用中的参数处理

存储过程本身如果内部使用了动态SQL拼接，同样存在注入风险。调用存储过程时使用预编译的CallableStatement可以防止调用层面的注入，但无法防止存储过程内部的拼接漏洞。例如：

CREATE PROCEDURE search_articles(IN keyword VARCHAR(100))
BEGIN
    SET @sql = CONCAT('SELECT * FROM articles WHERE title LIKE ''%', keyword, '%''');
    PREPARE stmt FROM @sql;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END

这个存储过程内部使用了CONCAT拼接SQL，keyword参数中的单引号可以闭合字符串，导致注入。即使调用方使用了CallableStatement并正确绑定参数，存储过程内部的漏洞依然存在。修复方式是在存储过程内部也使用参数化查询，或者避免在存储过程中使用动态SQL。调用方无法控制存储过程内部的行为，因此需要审查存储过程代码本身。

错误用法八：忽略数据库驱动的预编译实现差异

不同数据库驱动对预编译的支持程度不同。MySQL的JDBC驱动默认情况下useServerPrepStmts参数为false，这意味着JDBC驱动在客户端模拟预编译，实际发送给数据库的是已经替换好参数的完整SQL。这种情况下，参数值虽然在客户端进行了转义处理，但本质上仍然是把参数拼进SQL再发送。如果转义逻辑存在缺陷，或者遇到特殊字符集问题，仍有可能被绕过。建议在MySQL连接URL中显式开启服务端预编译：

jdbc:mysql://localhost:3306/mydb?useServerPrepStmts=true&cachePrepStmts=true

开启useServerPrepStmts后，驱动会使用真正的服务端预编译协议，参数与SQL结构在数据库层面分离，安全性更高。不过需要注意，某些场景下服务端预编译可能带来性能开销，需要根据实际情况测试。PostgreSQL默认使用服务端预编译，Oracle也支持服务端预编译。了解所用数据库驱动的默认行为，是确保预编译真正生效的前提。

错误用法九：多语句执行场景

某些数据库驱动默认允许在一条SQL中执行多个语句，例如MySQL的allowMultiQueries参数。如果开启了这个选项，并且代码中存在拼接漏洞，攻击者可以构造多语句注入，例如在正常查询后追加DROP TABLE或UPDATE语句。预编译语句本身不支持多语句参数绑定，但如果SQL模板是通过拼接得到的，攻击者可以在参数值中插入分号和第二条恶意语句。即使使用预编译，如果SQL模板本身包含拼接内容，多语句执行仍然可能被触发。建议在数据库连接配置中关闭allowMultiQueries，除非业务确实需要，并且所有SQL都经过严格审查。

实际开发中的检查清单

要确保预编译语句真正发挥作用，开发团队可以建立以下检查项：第一，代码中所有SQL字符串是否包含用户输入的直接拼接，尤其是prepareStatement调用之前的拼接；第二，动态表名、列名、排序字段是否经过白名单校验；第三，IN子句是否使用动态占位符而非字符串拼接；第四，LIKE查询的通配符是否在参数值中拼接；第五，ORM框架中的动态SQL是否使用了安全的占位符语法；第六，存储过程内部是否存在动态SQL拼接；第七，数据库驱动是否开启了服务端预编译；第八，数据库连接是否关闭了不必要的多语句执行选项。这些检查项可以集成到代码审查流程中，也可以使用静态代码扫描工具辅助检测。

预编译语句是防御SQL注入的基石，但它不是银弹。只有理解其工作机制，避免上述常见误用，才能让预编译真正成为安全防线的一部分。安全是一个系统工程，预编译之外，还需要配合输入验证、最小权限原则、错误信息处理、定期安全测试等多层防护措施。对于已经上线的系统，建议使用自动化工具扫描SQL注入漏洞，并针对发现的拼接点逐一修复。

防止SQL注入预编译语句避坑指南

服务指南

帮助中心