1. 项目概述：为什么SQL注入是Java开发者的“必修课”

如果你是一名Java后端开发者，或者正在准备Java相关的面试，那么“SQL注入”这个词你一定不陌生。它几乎出现在每一份Java面试八股文的清单里，从“Java基础面试题”到“Java面试必备八股文”，再到各种靶场（如DVWA、Pikachu、CTFHub）的实战题目，SQL注入都是绕不开的核心考点。但它的意义远不止于应付面试。在实际开发中，一个疏忽的SQL注入漏洞，轻则导致数据泄露、业务逻辑混乱，重则可能让整个数据库被拖库、服务器被控制，给企业带来毁灭性打击。我见过太多因为一个简单的字符串拼接，导致用户表被清空、管理员密码被篡改的线上事故。因此，理解并防御SQL注入，不是一项可选技能，而是Java开发者保障系统安全底线的“必修课”。本文将从一线开发的视角，彻底拆解SQL注入的原理、攻击手法、在Java项目中的真实案例，以及最有效的防御方案，让你不仅知其然，更知其所以然，写出真正安全的代码。

2. SQL注入核心原理与攻击手法深度拆解

2.1 漏洞的本质：程序与数据的边界模糊

要理解SQL注入，首先要明白一个核心概念： 代码与数据的混淆 。在一条SQL语句中，有一部分是固定的程序逻辑（如 SELECT * FROM users WHERE username = ），另一部分是可变的数据（如用户输入的 ‘admin’ ）。SQL注入攻击的成功，正是因为恶意数据“越界”闯入了程序逻辑的领地，被数据库引擎误认为是可执行的代码。

用一个最经典的例子来说明。假设我们有一个用户登录的Java代码，使用原始的字符串拼接来构造SQL：

String username = request.getParameter(“username”); // 用户输入
String password = request.getParameter(“password”); // 用户输入
String sql = “SELECT * FROM users WHERE username = ‘“ + username + “’ AND password = ‘“ + password + “’”;
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

这段代码的逻辑看起来很直观：拼接用户输入的用户名和密码，形成查询语句。如果用户老老实实输入 admin 和 123456 ，那么生成的SQL是：

SELECT * FROM users WHERE username = ‘admin’ AND password = ‘123456’

这没有问题。但是，如果攻击者在用户名输入框中输入的不是 admin ，而是 admin’ -- （注意最后有一个空格），密码任意输入，比如 xxx ，那么拼接后的SQL语句就变成了：

SELECT * FROM users WHERE username = ‘admin’ -- ’ AND password = ‘xxx’

在SQL中， -- 是单行注释符，它意味着后面的所有内容都会被数据库忽略。于是，这条SQL的实际执行逻辑变成了：

SELECT * FROM users WHERE username = ‘admin’

攻击者成功绕过了密码验证，仅凭用户名就登录了系统。 这就是一次典型的“永真条件”注入。数据（ admin’ -- ）中的单引号 ’ 提前闭合了原SQL中的字符串，而 -- 则注释掉了后续的验证逻辑，将数据部分变成了影响程序逻辑的“代码”。

2.2 攻击手法的“武器库”：不止于绕过登录

很多初学者以为SQL注入就是绕过登录，其实它的攻击手法丰富得多，危害也大得多。根据注入点、数据库类型、防护措施的不同，攻击手法千变万化。

1. 联合查询注入（Union-Based） 这是信息窃取最直接的方式。攻击者利用 UNION 操作符，将恶意查询的结果拼接到原始查询结果中，从而盗取其他表的数据。例如，在查询商品时注入：

‘ UNION SELECT username, password FROM users --

这要求攻击者需要知道前后查询的列数必须一致，通常会先用 ORDER BY 或 UNION SELECT NULL, NULL... 来探测列数。在CTF题目和Pikachu靶场中，这是非常常见的题型。

2. 报错注入（Error-Based） 当页面会回显数据库错误信息时，攻击者可以故意构造错误的SQL语句，让数据库在报错信息中“吐”出我们想要的数据。例如，利用 extractvalue() 或 updatexml() 函数的参数错误：

‘ AND extractvalue(1, concat(0x7e, (SELECT version()), 0x7e)) --

错误信息可能会包含 XPATH syntax error: ‘~5.7.36~’ ，这样我们就得到了数据库版本号。这种手法在“文章管理系统sql注入”、“avcon综合管理平台sql注入漏洞”这类实际漏洞案例中经常出现，因为开发人员为了方便调试，默认开启了错误回显。

3. 布尔盲注（Boolean-Based Blind） 当页面没有明确的数据回显和错误信息时，攻击者通过观察页面返回结果的 细微差异 （如内容是否存在、响应时间长短、HTTP状态码）来逐位推断数据。例如：

‘ AND ascii(substr(database(),1,1)) > 100 --

如果页面正常显示，说明数据库名第一个字符的ASCII码大于100；如果页面异常或为空，则说明小于等于100。通过二分法等技巧，可以像“闭着眼睛摸象”一样，慢慢还原出完整数据。这个过程非常耗时，但自动化工具（如sqlmap）可以轻松完成。

4. 时间盲注（Time-Based Blind） 这是布尔盲注的升级版，当页面连任何可见的差异都没有时使用。攻击者通过构造让数据库执行延迟的语句，根据 响应时间 来判断条件真假。例如在MySQL中：

‘ AND IF(ascii(substr(database(),1,1))>100, sleep(5), 0) --

如果页面响应延迟了5秒，说明条件为真。这种攻击更加隐蔽，但同样可以通过工具自动化。

5. 堆叠查询（Stacked Queries） 利用分号 ; 在一次数据库调用中执行多条SQL语句。这是最危险的一种，因为它可以直接执行任意数据库命令。例如：

‘; DROP TABLE users; --

如果数据库连接权限足够高（在Java中，如果使用具有高权限的数据库账号），这条语句会直接删除用户表。在“sqli测试环境中使用工具sqlmap进行sql注入攻击”的练习中，常常会用到这种手法来证明漏洞的危害性。

注意 ：不是所有数据库驱动和编程接口都支持堆叠查询。例如，Java的 Statement 接口默认是支持的，但很多ORM框架或连接池会禁用它。然而，绝不能依赖于此作为安全措施。

2.3 从原理看防御：为什么参数化查询是“银弹”

理解了攻击原理，防御思路就清晰了： 必须严格区分代码（SQL结构）和数据（用户输入） 。最根本、最有效的方法就是使用 预编译语句（PreparedStatement） ，也就是常说的参数化查询。

它的工作原理是： 将SQL语句的模板预先发送给数据库进行编译和优化。在这个模板中，所有可变的数据部分都用占位符（ ? ）代替。 编译完成后，模板的结构就固定了。之后，无论传入什么样的数据，数据库都只会将其视为纯粹的“数据值”来填充到对应的占位符中，而绝不会将其解释为SQL代码的一部分。

用代码对比一下： 危险的做法（拼接）： 

String sql = “SELECT * FROM products WHERE category = ‘“ + userInput + “’”;
Statement stmt = conn.createStatement();
stmt.executeQuery(sql); // 输入 `‘ OR ‘1’=‘1` 即可注入

安全的做法（参数化）： 

String sql = “SELECT * FROM products WHERE category = ?”;
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, userInput); // 即使输入 `‘ OR ‘1’=‘1`，也会被当作一个完整的字符串值
ResultSet rs = pstmt.executeQuery();

在第二种方式中，即使用户输入了 ‘ OR ‘1’=‘1 ，最终数据库执行的语句等价于：

SELECT * FROM products WHERE category = ‘‘ OR ‘1’=‘1’

数据库会去寻找 category 字段值 等于这个奇怪字符串 ‘ OR ‘1’=‘1‘ 的记录，而不会将其中的 OR 当作逻辑运算符。因为语句结构在预编译时已经确定， WHERE 子句后面就是一个等于条件判断，输入的内容只是这个判断的值而已。

这就是为什么参数化查询能从根源上防御绝大多数SQL注入。它通过数据库协议层面的机制，确保了数据和指令的分离。

3. Java项目中SQL注入的实战场景与深度防御

3.1 不止于JDBC：现代框架中的风险点

很多开发者认为，只要用了MyBatis、JPA（Hibernate）等ORM框架就高枕无忧了。这是一个极其危险的误区。 框架是工具，工具用得不对，一样会产生漏洞。

1. MyBatis中的“ ${} ”陷阱 MyBatis提供了两种参数占位符： #{} 和 ${} 。

  • #{} ：是安全的，它会被解析为JDBC的 PreparedStatement 参数占位符 ? ，实现预编译。
  • ${} ：是危险的，它直接进行字符串替换（文本替换），等同于SQL拼接。

错误示例（在XML映射文件中）：

<select id=“findByOrder” resultType=“Order”>
  SELECT * FROM orders ORDER BY ${orderByField}
</select>

如果 orderByField 参数来自用户前端选择（如 create_time ），这看起来没问题。但如果攻击者能够控制这个参数，传入 create_time; DROP TABLE users -- ，后果不堪设想。更常见的是，攻击者传入 (CASE WHEN (SELECT …) THEN id ELSE amount END) 这类子查询，实现盲注。

正确做法 ：

  • 对于 ORDER BY 、 GROUP BY 、表名、列名等 SQL关键字或标识符 ，如果必须动态传入， 绝对不要直接使用 ${} 。应该在后端代码中建立一个合法的字段值白名单进行校验。
// 白名单校验
private static final Set<String> ALLOWED_ORDER_FIELDS = Set.of(“id”, “create_time”, “amount”);
public String validateOrderField(String input) {
    if (!ALLOWED_ORDER_FIELDS.contains(input)) {
        return “id”; // 或抛出异常
    }
    return input;
}
// 在Mapper接口中，使用安全的`#{}`传递经过校验的值（注意：`#{}`用于标识符时需要特殊处理，通常更推荐用`${}`+白名单，但需确保白名单绝对可靠）
// 或者，更安全的是在Java代码中拼接SQL片段。

2. JPA/Hibernate的“JPQL/SQL拼接”风险 使用JPA的 createQuery 或 createNativeQuery 时，如果手动拼接字符串，风险与JDBC的 Statement 完全一样。

// 危险！拼接JPQL
String jpql = “SELECT u FROM User u WHERE u.username = ‘“ + username + “’”;
Query query = entityManager.createQuery(jpql);
// 危险！拼接原生SQL
String sql = “SELECT * FROM users WHERE username = ‘“ + username + “’”;
Query query = entityManager.createNativeQuery(sql, User.class);

正确做法 ：使用参数化查询。

// 安全的JPQL参数化
String jpql = “SELECT u FROM User u WHERE u.username = :uname”;
Query query = entityManager.createQuery(jpql).setParameter(“uname”, username);
// 安全的原生SQL参数化（位置参数）
String sql = “SELECT * FROM users WHERE username = ?1”;
Query query = entityManager.createNativeQuery(sql, User.class).setParameter(1, username);

3. 复杂查询构建器的疏忽 在使用JPA Specification、QueryDSL或MyBatis-Plus的 Wrapper 时，如果通过字符串拼接构造条件，同样存在风险。

// 错误示例：MyBatis-Plus中错误的用法（假设wrapper条件来自不可信输入）
String userInput = “admin’ OR ‘1’=‘1”;
QueryWrapper<User> wrapper = new QueryWrapper<>();
wrapper.eq(“username”, userInput); // 这个eq方法是安全的，因为它内部使用预编译
wrapper.apply(“column = ‘“ + userInput + “’”); // 危险！`apply`方法直接拼接SQL片段

apply() 、 last() 等方法用于直接插入SQL片段，必须确保片段内容完全可控或经过严格过滤。

3.2 纵深防御：除了参数化，我们还能做什么？

参数化查询是基石，但安全的城墙需要多层防御。

1. 输入验证与过滤

  • 原则 ：在数据到达数据库层之前，尽早进行验证。
  • 白名单优于黑名单 ：对于已知的、有限集合的输入（如状态码、类型枚举），使用白名单校验。例如，订单状态只允许“待支付”、“已发货”等几个固定值。
  • 对自由输入进行规范化 ：对于用户名、搜索关键词等自由文本，可以设定合理的长度限制、字符集限制（如只允许中英文、数字和常见符号），过滤掉明显的SQL元字符（如单引号、分号、注释符）。但要注意， 过滤不能替代参数化 ，它只是增加攻击难度的辅助手段。因为过滤规则可能被绕过（如双写、编码绕过）。

2. 最小权限原则

  • 应用数据库账户权限限制 ：为Web应用程序配置的数据库连接账号， 绝对不能是 root 或 sa 等超级管理员账号 。应该创建一个仅拥有当前应用所需 最小权限 的账号。例如，一个只读的报表查询应用，就应该使用一个只有 SELECT 权限的账号。这样即使发生注入，攻击者也无法执行 DROP 、 UPDATE 、 INSERT 等破坏性操作。
  • 网络与访问层隔离 ：数据库服务器不应直接暴露在公网，应置于内网，通过应用服务器访问。这能防止攻击者直接针对数据库端口进行攻击。

3. 避免敏感信息泄露

  • 自定义错误页面 ：在生产环境中，务必关闭详细的数据库错误回显。不要将包含数据库结构、SQL语句片段、路径等信息的错误堆栈直接展示给用户。应使用统一的、友好的错误页面。这在Spring Boot中可以通过 server.error.whitelabel.enabled=false 并配置自定义的 ErrorController 来实现。
  • 日志脱敏 ：确保日志系统中不会记录完整的、包含用户输入的SQL语句。如果使用Logback或Log4j2记录MyBatis SQL日志，要确保参数化后的日志模式，避免记录拼接后的原始SQL。

4. 使用安全的开发工具与组件

  • ORM框架 ：优先使用Spring Data JPA、MyBatis（正确使用 #{} ）等成熟框架，它们提供了相对安全的抽象。但务必阅读文档，了解其安全边界。
  • SQL防注入库 ：对于极其复杂的、必须动态拼接SQL的场景（如动态报表），可以考虑使用像 jOOQ 这样的类型安全SQL构建库，或者Apache的 commons-text 中的 StringEscapeUtils （但需谨慎，转义规则因数据库而异）。
  • 代码审计工具 ：在CI/CD流程中集成静态应用安全测试（SAST）工具，如SonarQube、Checkmarx、Fortify等，它们可以自动扫描代码库中的SQL拼接漏洞。

3.3 高级话题：预编译语句的“失效”场景与应对

预编译语句并非万能，在极少数特殊场景下，如果使用不当，其防护效果会打折扣。

1. 预编译语句的“模拟”模式 某些旧的数据库驱动或连接池（如某些版本的MySQL驱动在特定配置下），为了提升性能，可能会在客户端“模拟”预编译，而不是真正发送到数据库服务器进行预编译。在这种模式下，驱动可能仍然在底层进行字符串拼接，然后再发送整条SQL到数据库。这就绕过了数据库端的防护机制。 应对 ：确保JDBC URL或连接配置中，强制使用真正的服务器端预编译。例如，对于MySQL，可以添加参数 useServerPrepStmts=true 。

spring.datasource.url=jdbc:mysql://localhost:3306/db?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true

2. IN语句的动态参数问题 这是一个经典难题。当查询条件是一个动态的、长度不定的列表时，例如 SELECT * FROM users WHERE id IN (?, ?, ?) ，占位符的数量需要动态生成。

// 难点：参数个数不确定
List<Integer> idList = Arrays.asList(1, 2, 3, 4);
String placeholders = String.join(“,”, Collections.nCopies(idList.size(), “?”));
String sql = “SELECT * FROM users WHERE id IN (“ + placeholders + “)”;
PreparedStatement pstmt = conn.prepareStatement(sql);
for (int i = 0; i < idList.size(); i++) {
    pstmt.setInt(i + 1, idList.get(i));
}

虽然这里拼接了SQL字符串（ IN (?, ?, ?, ?) ），但拼接的是 占位符本身 ，而不是用户数据。占位符是SQL语法的一部分，在预编译阶段就已经确定，因此是安全的。关键在于，我们拼接的内容必须是完全可控的、非用户直接输入的语法元素。

3. 动态表名/列名 如前所述，表名和列名不能使用占位符。必须通过白名单机制来解决。

// 安全做法：白名单映射
private static final Map<String, String> ALLOWED_TABLE_NAMES = Map.of(
    “user”, “t_user_info”,
    “order”, “t_order_main”
);
public String getSafeTableName(String input) {
    String tableName = ALLOWED_TABLE_NAMES.get(input);
    if (tableName == null) {
        throw new IllegalArgumentException(“Invalid table identifier”);
    }
    return tableName;
}
// 拼接SQL时使用安全的表名
String safeTable = getSafeTableName(userInputTableParam);
String sql = “SELECT COUNT(*) FROM “ + safeTable;
// 注意：此处拼接了表名，但因为safeTable来自白名单，所以安全。

4. 从攻击者视角进行防御：渗透测试与代码审计实战

最好的防御是理解攻击。作为开发者，偶尔切换视角，用攻击者的思维审视自己的代码，能发现很多潜在问题。

4.1 利用靶场进行自我训练

网络热词中提到的DVWA、Pikachu、SQLi-Labs、CTFHub技能树等，都是绝佳的练习环境。不要只满足于用自动化工具（如sqlmap）跑出结果，要尝试 手工注入 ，理解每一步的原理。

以Pikachu靶场的“字符型注入”为例，手工注入流程：

  1. 探测注入点 ：在输入框输入 kobe‘ ，观察页面是否报错或回显异常。如果报错，说明可能存在注入。
  2. 判断闭合方式与注释 ：输入 kobe‘ and ‘1’=‘1 和 kobe‘ and ‘1’=‘2 ，观察页面差异。如果前者正常后者异常，说明是单引号字符串闭合，且 and 逻辑被执行。为了简化后续payload，通常会使用注释符 --+ 或 # 来注释掉原SQL后面的部分。
  3. 判断列数 ：使用 order by 语句。 kobe‘ order by 1 --+ ， order by 2 --+ … 直到页面出错，出错前的数字就是查询的列数。
  4. 确定回显点 ：使用 union select 。 kobe‘ union select 1,2,3 --+ （假设列数为3）。观察页面中原本显示数据的位置，是否被数字1,2,3替换。这些位置就是我们可以回显查询结果的位置。
  5. 获取信息 ：在回显点替换为我们想要的查询。例如，在位置2显示数据库名： kobe‘ union select 1, database(), 3 --+ 。进而可以查询 version() 、 user() ，以及通过 information_schema 库查询表名、列名。
  6. 获取数据 ： kobe‘ union select 1, username, password from users --+ 。

这个过程能让你深刻理解SQL注入是如何一步步获取信息的。在“dc-9靶场sql手工注入流程”这类实战中，你还会遇到需要绕过WAF、需要二次注入等更复杂的情况。

4.2 代码审计实战：寻找项目中的“坏味道”

定期Review自己或团队的代码，寻找SQL注入的“坏味道”：

  • 全局搜索 Statement ：在项目中搜索 createStatement() 、 executeUpdate( 、 executeQuery( 等关键词，检查是否与用户输入有拼接。
  • 搜索MyBatis的 ${} ：在XML映射文件中搜索 ${ ，逐一审查其使用场景。确认它是否用于拼接用户输入的数据（而不是固定的、内部可控的标识符）。
  • 审查拼接字符串的SQL构建方法 ：关注任何使用 StringBuilder 、 String.format 、 “+” 运算符来构建SQL字符串的方法。
  • 审查Native Query ：在JPA项目中，搜索 createNativeQuery 和 @NamedNativeQuery 注解，检查其SQL字符串是否安全。

一个典型的审计案例： 假设在代码中看到这样一个方法：

public List<Order> findOrders(String status, Date startDate, String sortBy) {
    String sql = “SELECT * FROM orders WHERE 1=1”;
    if (status != null) {
        sql += “ AND status = ‘“ + status + “’”; // 高危！
    }
    if (startDate != null) {
        sql += “ AND create_time >= ‘“ + startDate.toString() + “’”; // 日期转换，可能安全，但格式依赖
    }
    if (sortBy != null) {
        sql += “ ORDER BY “ + sortBy; // 高危！sortBy可能被注入
    }
    // ... 执行查询
}

这里有两处高危：

  1. status 直接拼接，可注入。
  2. sortBy 直接拼接，可注入（虽然不能直接查数据，但可通过 CASE WHEN 子查询进行盲注，或引发错误）。 修复方案 ：将整个查询重构为使用 PreparedStatement ，对于 WHERE 条件使用参数 ? ，对于 ORDER BY 使用白名单校验 sortBy 参数。

4.3 常见问题与排查技巧实录

在实际开发和维护中，即使知道了最佳实践，也可能会遇到一些棘手的问题。

问题1：使用了PreparedStatement，但日志里看到的SQL还是被注入了？ 这通常是日志记录方式的问题。很多框架（如MyBatis）在DEBUG级别下会打印两种SQL日志：

  • Preparing: 显示带 ? 的SQL模板。
  • Parameters: 显示参数值。
  • ==> Executing: 显示的是驱动或框架在 本地 拼接好的、完整的SQL语句，用于方便开发者调试。 这并不意味着注入发生了 ，这只是日志的一种呈现方式。真正的执行发生在数据库端，传入的是预编译的模板和参数列表。只要确认代码中用的是 #{} 或 PreparedStatement.setXXX() ，就是安全的。

问题2：存储过程或函数调用也存在注入风险吗？ 是的。如果使用字符串拼接来调用存储过程，同样危险。

// 错误
String callSql = “{call get_user_data(‘“ + userName + “‘)}”;
// 正确：使用CallableStatement和参数占位符
String callSql = “{call get_user_data(?)}”;
CallableStatement cs = conn.prepareCall(callSql);
cs.setString(1, userName);

问题3：LIKE语句中的通配符如何处理？ 在LIKE查询中，用户输入可能包含SQL通配符 % 和 _ ，这虽然不属于注入，但会导致查询结果与预期不符（如搜索 % 会匹配所有记录）。

PreparedStatement pstmt = conn.prepareStatement(“SELECT * FROM products WHERE name LIKE ?”);
pstmt.setString(1, “%” + userInput + “%”); // 如果userInput包含`%`，会改变匹配逻辑

处理方案 ：对用户输入中的通配符进行转义（注意，转义字符因数据库而异）。例如，在MySQL中：

String escapedInput = userInput.replace(“%”, “\\%”).replace(“_”, “\\_”);
pstmt.setString(1, “%” + escapedInput + “%”);

或者，在应用层明确告知用户 % 和 _ 是通配符，并提供转义选项。

问题4：如何对现有的、庞大的遗留系统进行SQL注入修复？ 这是一个渐进的过程：

  1. 风险评估 ：使用SAST工具进行全量扫描，定位最高危的点（如搜索功能、登录功能、订单查询）。
  2. 优先修复 ：按照风险等级，优先修复对外暴露的、涉及核心数据的接口。
  3. 建立规范 ：制定团队SQL编写规范，强制要求新代码使用参数化查询或安全的ORM方法。
  4. 中间件防护 ：在数据库前部署WAF（Web应用防火墙），作为一种临时的、边界性的防护措施。但 绝不能 依赖WAF代替代码修复，WAF规则可能被绕过。
  5. 持续教育 ：在团队内进行安全编码培训，将SQL注入案例纳入Code Review的必查项。

SQL注入是一个“古老”但远未过时的话题。它考验的不仅是开发者的安全知识，更是其严谨的编码习惯和对“用户输入皆不可信”这一安全基石的深刻认同。从今天起，在写下每一行与数据库交互的代码时，都问自己一句：“这里的数据，被恶意构造了怎么办？” 多这一份警惕，你的系统就多一份坚实。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

2026年AI写作辅助平台推荐：9款高效AI工具终极指南

avatar 亚马逊云科技技术品牌专区
cover

TVA对具身智能领域“莫拉维克悖论“的挑战（19）

avatar 亚马逊云科技技术品牌专区
cover

WSaiOS认知内核：一种模块化可解释人工智能操作系统核心的设计与实现

avatar 亚马逊云科技技术品牌专区