Java 防 SQL 注入全攻略：从预编译到参数化查询的实战要点

Java 防 SQL 注入全攻略的理论基础

注入向量与数据库攻击面

在数据库应用中，SQL 注入是通过将恶意输入嵌入 SQL 语句来改变查询逻辑的攻击手段，攻击面主要来自未经过滤的输入、拼接的 SQL 字符串以及直接暴露的数据库错误信息。攻击面越宽，风险越大，因此需要从输入层、应用层到数据库层建立多重防线。只有明确认识到注入向量，才能在后续的实现中采用更安全的写法。

常见的攻击向量包括直接的字符串拼接、动态生成的 SQL、以及不恰当的类型转换，这些行为往往使数据库解释执行意外的查询。拼接字符串是最容易被误用的路径，开发者若忽视对输入参数的控制，极易被注入恶意 SQL 片段。面对这些风险，正确的设计应将输入清洗和参数化处理作为第一道防线。

// 漏洞示例：直接拼接用户输入
String sql = "SELECT * FROM users WHERE username = '" + userInput + "' AND status = 1";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

在上面的示例中，用户输入直接拼接到 SQL中，导致未经滤的内容进入查询逻辑，极易被利用。后续将从预编译与参数化查询角度，讲解如何规避这些风险。

从预编译到参数化查询的要点

实现防注入的核心在于理解预编译与参数化查询的区别：预编译让数据库先解析 SQL 结构，再绑定参数；参数化查询通过使用占位符“?”，在执行阶段再把参数值绑定进来，彻底消除了字符串拼接带来的风险。该思路也是 Java 语言生态中的主流做法。

在实际开发中，使用占位符“?”并结合setXXX方法来绑定参数，是实现参数化查询的标准姿势。通过这种方式，用户输入仅作为数据传递，而非 SQL 结构的一部分，从而避免了注入攻击的可能性。

// 安全示例：使用参数化查询
String sql = "SELECT * FROM users WHERE username = ? AND status = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, username);
pstmt.setInt(2, status);
ResultSet rs = pstmt.executeQuery();

需要强调的是，避免直接拼接参数，即使参数来自受信任的数据源，也应通过绑定来传递。若涉及到不同数据类型，使用对应的set方法（如setString、setInt、setDate等）确保数据库端类型的一致性。

在 Java 中实现预编译与参数化查询的实战要点

JDBC 的基本用法与注意事项

在 Java 层面，正确的生命周期管理是关键：获取连接、创建 PreparedStatement、绑定参数、执行查询/更新、以及最后的资源释放。通过try-with-resources可以确保在异常情况下也能自动关闭，避免连接泄漏。

为了达到最好的可维护性，应该将 SQL 语句与参数分离，避免在代码中硬编码复杂字符串。资源关闭和异常处理也需要考虑，确保日志不暴露敏感信息。

try (Connection conn = dataSource.getConnection();PreparedStatement ps = conn.prepareStatement("SELECT id, username FROM users WHERE id = ?")) {ps.setLong(1, userId);try (ResultSet rs = ps.executeQuery()) {while (rs.next()) {// 处理结果}}
} catch (SQLException e) {// 记录并上抛或处理
}

参数绑定的正确姿势

不同数据类型应使用相应的 setXXX 方法进行绑定，不要将所有参数都绑定为 Object，以避免数据库类型推断错误。对日期、时间和时间戳等类型，考虑时区和数据库端类型的一致性，必要时使用 setDate/setTimestamp 等方法。

在复杂查询中，可以通过将输入参数进行基本校验或格式化后再绑定，确保多数异常在绑定阶段就被捕获，避免在执行阶段出现意料之外的行为。参数校验在防注入中具备前置防线作用。

// 参数绑定示例：类型安全
String sql = "UPDATE orders SET status = ? WHERE order_id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, "SHIPPED"); // 绑定字符串
ps.setLong(2, orderId);     // 绑定数字
ps.executeUpdate();

避免 SQL 拼接：从风险到安全

动态 SQL 与白名单策略

动态 SQL（根据条件拼接的查询）是造成注入的高风险区域。优先采用固定结构的 SQL，将可变部分放入参数，必要时使用白名单来限定列名、表名等不可绑定的结构化部分。

对必须的动态部分，尽量通过框架提供的安全机制实现，如 MyBatis 的动态 SQL 条件、JPA 的 Criteria API 等。只有将可变结构作为参数传递，而非 SQL 字符串拼接，才符合防注入的最佳实践。

// 动态 SQL 但通过参数化处理示例（伪代码，实际需结合框架能力）
String base = "SELECT * FROM orders WHERE 1=1";
List