防止SQL注入的JDBCStatement使用警告与代码审查要点

JDBC的Statement接口，尤其是最基础的java.sql.Statement，是Java开发者在早期学习数据库连接时最先接触的API。它简单直接，通过字符串拼接的方式构建SQL语句，但正是这种“灵活性”，为SQL注入攻击敞开了大门。攻击者可以在任何接收用户输入并拼接进SQL的字段中注入恶意代码，从而绕过认证、窃取数据、篡改记录甚至删除整个数据库。问题的核心不在于Statement本身有漏洞，而在于开发者将不可信的数据与SQL指令未经隔离就混合在一起。当你在代码中看到类似 "SELECT * FROM users WHERE name = '" + userName + "'" 这样的写法时，就已经构成了严重的安全隐患。

SQL注入的本质是注入的恶意数据被数据库解析器当作SQL指令的一部分执行了。正常的SQL语句中，数据部分（如字符串字面量）是被引号包围的，解析器知道那是值，不是命令。但动态拼接时，如果输入数据中包含了引号闭合符和额外的SQL关键字，解析器就会将其识别为新的指令。例如，用户输入 ' OR '1'='1，拼接后的SQL变成 SELECT * FROM users WHERE name = '' OR '1'='1'，这永远返回真，从而绕过了身份验证。更危险的是，攻击者可以利用分号执行多语句，或者使用UNION查询窃取其他表的数据，甚至调用xp_cmdshell等存储过程执行操作系统命令。这一切的根源都是因为开发者用字符串拼接的方式模糊了程序逻辑与数据之间的清晰界限。

第一种高危用法是直接拼接用户输入构造WHERE子句条件。这在登录验证、搜索功能、数据筛选等场景中极其常见。例如，一个看似无害的搜索框，后端代码为 Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("SELECT * FROM products WHERE name LIKE '%" + keyword + "%'"); ，攻击者输入 %'; DROP TABLE products; -- 就可能造成灾难性后果。第二种高危用法是动态拼接表名、列名或排序字段。很多开发者认为这些结构部分无法使用预编译参数，只能拼接，于是写出了 "SELECT * FROM " + tableName + " ORDER BY " + sortColumn 这样的代码。如果tableName或sortColumn来自前端参数，攻击者可以通过篡改这些值探测数据库结构或执行盲注。第三种高危用法是在INSERT或UPDATE语句中拼接值，例如 "INSERT INTO users (name, email) VALUES ('" + name + "', '" + email + "')" 。即使只是插入数据，攻击者也可以利用子查询或特殊函数窃取信息，或者构造恶意数据存储到数据库中，形成二阶SQL注入——这些数据在后续被其他查询读取并拼接执行时才会触发攻击。

在代码审查中，第一步是全局搜索 new Statement 或 Connection.createStatement() 的调用。不要被间接调用所迷惑，有些框架封装了原生JDBC，底层仍然是Statement。审查时需要关注每一个Statement实例的executeQuery、executeUpdate、execute方法调用，检查其传入的SQL字符串参数是否包含任何变量拼接。即便变量不是直接来自HttpServletRequest，而是来自数据库、文件、消息队列等外部数据源，同样视为不可信数据。审查工具可以使用正则表达式搜索字符串拼接模式，例如加号连接符、String.format、StringBuilder.append、MessageFormat.format等，凡是SQL字符串中出现这些模式且涉及变量的，一律标记为高风险。同时要特别留意那些虽然使用了PreparedStatement但仅用于执行静态SQL的假预编译情况，有些开发者创建了PreparedStatement却仍然用字符串拼接传入SQL，这完全失去了防护意义。

PreparedStatement是防范SQL注入的核心武器，但前提是正确使用。审查时必须确认SQL语句中的所有变量部分都使用问号占位符代替，并且对应的参数通过setXxx方法设置。任何在SQL字符串中直接拼接变量后再传给PreparedStatement的写法都是无效的。例如 PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM users WHERE id = " + userId); 虽然使用了PreparedStatement，但SQL已经在传入前拼接完成，预编译机制形同虚设。正确的做法是 conn.prepareStatement("SELECT * FROM users WHERE id = ?")，然后 pstmt.setInt(1, userId)。审查时还要检查setXxx方法的参数索引是否正确、类型匹配是否恰当，避免因类型转换错误导致后续被迫改用拼接。对于IN子句这种需要动态数量参数的情况，不能因为占位符数量不确定就退回到拼接，而应该动态生成对应数量的占位符并循环设置参数。

预编译参数只能绑定数据值，不能绑定SQL语句的结构部分，如表名、列名、ORDER BY方向、LIMIT数值等。这些部分如果需要动态变化，绝不能直接拼接用户输入。审查时应检查这类代码是否采用了白名单验证机制。白名单意味着在服务端定义一个允许值的集合，将用户输入与集合中的值进行严格匹配，匹配不通过则拒绝执行或使用默认值。例如，排序字段只允许"id"、"username"、"create_time"这几个值，用户传入的值必须完全等于其中之一。不要使用黑名单过滤，因为攻击手法层出不穷，过滤总会有遗漏。对于表名，如果业务确实需要动态切换，可以考虑在数据库中使用视图或存储过程来抽象这层变化，或者在应用层通过映射关系将用户选择的逻辑表名转换为实际表名。审查时一旦发现表名、列名直接来自请求参数且没有白名单校验，应立即判定为严重漏洞。

很多开发者存在一个误区，认为使用了存储过程或Hibernate、MyBatis等ORM框架就天然免疫SQL注入。实际上，存储过程内部如果使用了动态SQL拼接（如MySQL的PREPARE语句、SQL Server的sp_executesql），并且拼接了外部传入的参数，同样存在注入风险。审查存储过程代码时，要关注EXEC、EXECUTE、sp_executesql等动态执行语句，检查其拼接的字符串中是否包含输入参数。对于ORM框架，要审查原生SQL查询和动态查询的使用方式。MyBatis中，应优先使用#{}占位符，它会被转换为预编译参数；而${}是直接字符串替换，仅应用于经过严格白名单验证的结构部分。Hibernate的HQL如果使用命名参数或位置参数是安全的，但createNativeQuery拼接字符串则不安全。JPA的Criteria API是类型安全的，但原生查询同样需要审查。审查时要特别注意框架配置中是否开启了动态SQL的某些灵活功能但未加以限制。

第一层是强制使用PreparedStatement进行参数化查询。在项目编码规范中明确禁止使用Statement进行带参数的SQL操作，仅允许在执行完全无变量的静态DDL语句时使用。可以通过IDE插件、代码扫描工具（如SonarQube、Fortify）在编码阶段自动检测违规代码。第二层是输入验证与过滤。虽然参数化查询是根本解决方案，但在数据进入系统的最外层进行严格的格式验证仍然有价值，可以拦截明显恶意的载荷，降低攻击面。验证规则应基于白名单，例如用户名只允许字母数字和下划线，长度限制在合理范围。第三层是数据库权限最小化。应用程序连接数据库的账号只应拥有执行必要操作的权限，严禁使用sa或root等高权限账号。即使发生注入，攻击者也无法执行DROP TABLE、xp_cmdshell等危险操作。第四层是部署Web应用防火墙（WAF），它可以在流量到达应用之前识别和阻断常见的SQL注入攻击模式，作为最后一道防线。第五层是错误信息屏蔽，生产环境绝不能将数据库的详细错误信息返回给客户端，这些信息会暴露数据库类型、表结构等敏感细节，为攻击者提供便利。

假设有一个用户注册功能，后端使用了安全的PreparedStatement： INSERT INTO users (username, email) VALUES (?, ?) 。数据被安全地存储到数据库中。几个月后，管理员需要导出一份用户列表，某个后台脚本使用了Statement拼接： SELECT * FROM users WHERE username = '" + usernameFromDB + "' 。由于usernameFromDB是从数据库中读取的，开发者认为这是“可信数据”，放松了警惕。但如果当初注册时，攻击者输入的用户名是 admin' -- ，这个恶意数据就被原封不动地存入了数据库。当后台脚本运行时，拼接出的SQL变成了 SELECT * FROM users WHERE username = 'admin' --' ，注释掉了后面的条件，可能返回了意料之外的数据集。这个案例揭示了一个关键原则：数据一旦来自系统外部，就永远不可信，无论它在内部经历了多少次流转和存储。代码审查时，必须追踪数据的完整生命周期，任何从数据库、缓存、文件、消息中间件中读取并用于SQL拼接的数据，都应视为不可信来源。

将SQL注入检测集成到CI/CD流水线中是保障代码质量的必要手段。静态应用安全测试工具（SAST）可以扫描源代码中的SQL注入模式，但需要针对JDBC的特定API进行规则配置。例如，可以编写自定义规则检测所有调用java.sql.Statement.executeQuery(String)且参数包含变量拼接的情况。动态应用安全测试工具（DAST）可以在应用运行时发送注入载荷，验证实际防护效果。在代码提交阶段，可以通过Git Hook触发轻量级扫描，发现高危模式直接阻断提交。在代码评审环节，应将JDBC相关代码作为必审项，审查清单包括：是否使用了Statement、PreparedStatement的占位符是否完整、动态结构部分是否有白名单、异常处理是否泄露信息。对于遗留系统，可以使用运行时防护技术（RASP）在JVM层面检测和阻断SQL注入攻击，为修复代码争取时间。

防止SQL注入的根本不在于学会了使用PreparedStatement的API，而在于培养一种将“数据”与“指令”严格分离的编程思维。每一次编写数据库访问代码时，都应该本能地审视：我是否在将不可信的数据混入SQL指令中？这种审视应该贯穿需求分析、设计、编码、审查、测试的全流程。技术层面，PreparedStatement解决了99%的注入问题，剩下的1%需要白名单验证、权限控制和纵深防御来覆盖。对于代码审查者而言，Statement的出现本身就是危险信号，动态拼接是不可逾越的红线。将这种安全意识和审查标准固化为团队的开发规范，并通过自动化工具持续验证，才能真正将SQL注入的风险降到最低。