Java开发中SQL注入防御全解析：从PreparedStatement到MyBatis最佳实践-编程阁

1. 项目概述：为什么SQL注入是Java开发者必须跨过的坎

干了这么多年Java后端开发，我处理过的线上安全事件里，SQL注入绝对能排进前三。这玩意儿不像内存溢出或者并发死锁那么“高级”，它更像是一个基本功，但偏偏很多工作三五年的兄弟，一被问到“Java里怎么防SQL注入”，回答还是停留在“用PreparedStatement”这个层面。这远远不够。SQL注入攻击能直接绕过应用层逻辑，对数据库进行非法操作，轻则数据泄露，重则整个库被拖走甚至服务器沦陷。尤其是在当前这个数据即资产的时代，一个因为字符串拼接导致的注入漏洞，足以让一个创业公司瞬间崩盘。

所以，今天我们不聊那些虚的，就扎扎实实地把Java里解决SQL注入这件事掰开揉碎了讲清楚。我会从最原始的JDBC讲到主流的MyBatis/MyBatis-Plus，不仅告诉你怎么做是对的，更会带你看看那些看似用了“正确”方法却依然翻车的经典错误案例。无论你是正在准备面试，被“八股文”里的SQL注入问题困扰，还是在实际开发中想构建更坚固的系统，这篇文章都能给你一套可直接落地的解决方案和排查思路。

2. 核心防御机制深度解析：从原理上理解为何有效

要真正解决一个问题，必须从根上理解它。SQL注入的本质，是“用户输入的数据”被错误地当成了“SQL代码的一部分”来执行。防御的核心思想，就是严格区分这两者：数据是数据，代码是代码。Java生态中主要的防御手段，都是围绕这个核心思想展开的。

2.1 预编译（PreparedStatement）是如何筑起第一道防线的

很多人知道要用PreparedStatement，但未必清楚它到底强在哪里。它的核心优势在于“预编译”和“参数化查询”。

当你创建一个PreparedStatement对象，并传入一条带占位符（?）的SQL时，比如SELECT * FROM user WHERE username = ? AND password = ?，数据库驱动会先将这条SQL语句的“模板”发送到数据库服务器。数据库服务器会对这个模板进行语法分析、编译和优化，生成一个执行计划。这个阶段，SQL语句的结构已经固定了：它知道这是一个查询，目标表是user，条件字段是username和password，而?只是两个等待填充的“空位”。

随后，当你调用setString(1, userInput)方法时，你传入的用户输入（哪怕它包含' OR '1'='1这样的恶意字符串）会被纯粹地当作一个字符串数据值，发送给数据库。数据库引擎会把这个值原封不动地填入之前编译好的执行计划中的对应“空位”。在整个过程中，用户输入的数据永远不会被重新解析为SQL语法。

这里有个关键点：预编译防注入的效果，依赖于数据库驱动和数据库协议的支持。以MySQL为例，要确保连接字符串中使用了useServerPrepStmts=true参数来开启真正的服务器端预编译。如果只用客户端模拟，在某些极端复杂的语句下仍可能存在风险。不过，现代主流驱动（如MySQL Connector/J）的默认行为或推荐配置都已足够安全。

2.2 MyBatis中#{}与${}的天壤之别

MyBatis作为持久层框架，简化了操作，但也引入了新的“坑点”。最经典的就是#{}和${}的区别，这几乎是Java面试的必考题。

#{}（井号大括号）是安全的参数占位符。MyBatis在处理它时，会将其转换为JDBC中的PreparedStatement的?占位符，从而实现参数化查询。例如：

<select id="selectUser" resultType="User"> SELECT * FROM user WHERE username = #{name} </select>

最终执行的SQL会是：SELECT * FROM user WHERE username = ?，参数name的值会被安全地设置进去。

${}（美元符号大括号）是字符串替换（或文本替换）。MyBatis会直接在SQL编译阶段，将${}中的内容原样替换到SQL语句中。例如：

<select id="selectUser" resultType="User"> SELECT * FROM user ORDER BY ${orderByColumn} </select>

如果orderByColumn这个参数来自用户输入且未被过滤，攻击者传入id; DROP TABLE user --，那么拼接后的SQL将变成SELECT * FROM user ORDER BY id; DROP TABLE user --，导致灾难性后果。

实操心得：在MyBatis的XML映射文件或注解中，对于所有来自用户输入、请求参数、外部接口的变量，必须使用#{}。${}仅能用于动态指定一些完全可控、非用户输入的部分，比如动态表名（需结合业务逻辑白名单校验）、动态列名（同样需白名单）等。我个人的代码规范是，使用${}必须附加注释，说明该参数为何安全，并经过组长Review。

2.3 并非用了预编译就万事大吉：常见的错误用法

这是很多中级开发者容易栽跟头的地方。他们知道要用PreparedStatement，但写法上却留下了后门。

错误案例1：部分拼接

String sql = "SELECT * FROM product WHERE category = ?"; if (StringUtils.isNotBlank(keyword)) { // 致命错误：在预编译语句创建后，又用字符串拼接了WHERE条件 sql += " AND name LIKE '%" + keyword + "%'"; } PreparedStatement ps = connection.prepareStatement(sql); ps.setString(1, category);

问题在于，prepareStatement(sql)调用时，SQL语句已经定型。后面追加的LIKE子句是通过字符串拼接直接嵌入的，keyword参数完全没有经过参数化处理，注入漏洞由此产生。

正确做法：必须将所有的可变参数都通过占位符?来传递。

String sql = "SELECT * FROM product WHERE category = ?"; List<Object> params = new ArrayList<>(); params.add(category); if (StringUtils.isNotBlank(keyword)) { sql += " AND name LIKE ?"; params.add("%" + keyword + "%"); // 通配符作为数据的一部分传入 } PreparedStatement ps = connection.prepareStatement(sql); for (int i = 0; i < params.size(); i++) { ps.setObject(i + 1, params.get(i)); }

错误案例2：IN语句的错误拼接批量查询时，经常需要WHERE id IN (1,2,3)。新手可能会这样写：

String ids = request.getParameter("ids"); // 假设ids="1,2,3" String sql = "SELECT * FROM user WHERE id IN (" + ids + ")"; // 直接拼接，高危！

或者试图用一个占位符解决：

String sql = "SELECT * FROM user WHERE id IN (?)"; ps.setString(1, "1,2,3"); // 这样设置，数据库会认为你查询的是 id='1,2,3'这个字符串，而非三个数字。

正确做法：需要根据参数列表的长度动态生成占位符。

List<Long> idList = Arrays.asList(1L, 2L, 3L); String placeholders = String.join(",", Collections.nCopies(idList.size(), "?")); String sql = String.format("SELECT * FROM user WHERE id IN (%s)", placeholders); PreparedStatement ps = connection.prepareStatement(sql); for (int i = 0; i < idList.size(); i++) { ps.setLong(i + 1, idList.get(i)); }

在MyBatis中，可以使用<foreach>标签安全地生成IN列表：

<select id="selectByIds" resultType="User"> SELECT * FROM user WHERE id IN <foreach collection="ids" item="id" open="(" separator="," close=")"> #{id} </foreach> </select>

3. 进阶防御与最佳实践：构建纵深防御体系

仅仅正确使用预编译，是“治标”。要“治本”，我们需要建立一个从输入到执行的多层防御体系。

3.1 输入验证与过滤：第一道闸门

永远不要相信前端传过来的任何数据。在数据进入业务逻辑层之前，进行严格的验证。

类型检查：对于ID、年龄等字段，在参数解析层（如Spring MVC的@RequestParam）就尝试转换为目标类型（Integer,Long）。转换失败则直接拒绝请求。
格式校验：使用正则表达式或验证框架（如Hibernate Validator）对邮箱、手机号、日期等字段进行格式校验。@Email,@Pattern等注解是很好的帮手。
长度限制：在数据库字段定义和代码逻辑中，对输入字符串长度进行限制，防止超长字符串攻击。
业务规则校验：比如订单状态只能从有限集合（如“待支付”，“已发货”）中选取，可以使用枚举或白名单校验。

注意事项：这里要避免一个误区——不要试图通过编写复杂的正则表达式来“过滤”SQL关键字（如SELECT, UNION, DROP, --）。这种方法被称为“黑名单过滤”，极易被绕过（如大小写变形、编码、注释符变种等）。输入验证的目的是保证数据符合业务规则，而不是扮演WAF（Web应用防火墙）的角色。真正的SQL注入防御应该交给参数化查询。

3.2 最小权限原则：数据库层面的最后堡垒

这是很多团队忽略的一点。你的应用连接数据库，不应该使用root或拥有DBA权限的账号。

创建专用应用账号：为每个应用或服务创建独立的数据库用户。
按需授权：这个账号只拥有它必须的权限。如果应用只需要读某个表，那就只授予SELECT权限。如果只需要增删改几个表，那就精确授予这几个表的INSERT,UPDATE,DELETE权限。坚决不授予DROP,CREATE,ALTER等结构变更权限。
好处：即使发生了最坏情况的SQL注入，攻击者也无法利用这个连接删除表、删除数据库或执行其他破坏性操作，能将损失控制在数据泄露层面，而不会导致服务完全不可用。

3.3 使用安全的ORM框架与插件

现代Java开发中，Spring Data JPA、MyBatis-Plus等框架提供了更高层次的抽象。

Spring Data JPA：默认使用Hibernate作为实现，其HQL（Hibernate Query Language）和Criteria API基本都是参数化绑定的，只要你不使用原生SQL（NativeQuery），就能有效避免SQL注入。但切记，如果必须使用@Query写原生SQL，一定要用?1、:name这样的参数绑定方式。
MyBatis-Plus：其提供的QueryWrapper、LambdaQueryWrapper等条件构造器，底层生成的SQL也是参数化的，比手动在XML中拼接${}安全得多。
安全插件：可以考虑在项目中集成安全插件，如mybatis-sql-inject-plugin，它能在运行时或代码审查阶段，扫描MyBatis Mapper XML文件中使用的${}，并给出警告或阻断，非常适合在CI/CD流程中集成。

3.4 日志与监控：发现异常的眼睛

完善的日志记录和监控是发现潜在攻击的重要手段。

记录完整SQL：在开发或测试环境，可以配置日志输出完整的、带参数的SQL语句（如MyBatis的log-impl: org.apache.ibatis.logging.stdout.StdOutImpl）。但在生产环境，务必谨慎，避免日志泄露敏感数据。
监控异常请求：关注那些包含大量SQL关键字（虽然不用于过滤，但可用于监控）、异常长的参数、短时间内大量重复的错误请求日志。这些可能是自动化注入工具（如sqlmap）在扫描的特征。
使用Web应用防火墙（WAF）：在应用前端部署WAF，可以拦截大量已知的、特征明显的SQL注入攻击载荷，为应用本身提供一个缓冲层。

4. 代码审计与漏洞排查实战指南

知道了怎么防御，我们还需要有能力发现现有代码中的漏洞。无论是审计自己的项目，还是面试时分析一段代码，这套方法都适用。

4.1 人工审计：抓住关键线索

人工审计的核心是“寻找字符串拼接”和“跟踪数据流”。

全局搜索：在IDE中全局搜索以下关键词：
- Statement（特别是createStatement）
- +（字符串连接符，结合SQL片段）
- append(（StringBuilder/StringBuffer拼接SQL）
- ${（在MyBatis XML或注解中）
- execute(、executeUpdate(、executeQuery(（查看其参数来源）
跟踪数据流：一旦发现可疑的拼接点，立刻向上跟踪这个拼接变量的来源。它是否来自：
- HttpServletRequest.getParameter()
- @RequestParam、@PathVariable（Spring MVC）
- 前端JSON/XML反序列化后的对象属性
- 外部RPC接口的返回值
- 数据库查询结果（二次注入）
判断是否可控：如果这个变量最终源头是用户输入、外部不可信接口，并且没有经过参数化查询（PreparedStatement的?或MyBatis的#{}），那么这里就存在SQL注入漏洞的高风险。

4.2 自动化工具辅助

人工审计耗时耗力，可以借助工具提高效率。

静态代码分析工具（SAST）：如Fortify SCA、Checkmarx、SonarQube（配合安全插件）。这些工具可以扫描源代码，基于数据流分析技术，识别出从用户输入点到危险函数（如SQL执行函数）的路径，并报告潜在的注入漏洞。它们能覆盖人工容易遗漏的复杂分支和间接调用。
IDE插件：一些IDE插件也能提供实时检查。例如，在IntelliJ IDEA中，如果你在Statement.executeQuery()中直接使用字符串拼接，IDE通常会给出警告。
MyBatis Mapper XML扫描脚本：可以写一个简单的脚本，扫描项目中的所有*.xml文件，查找包含${且不在<![CDATA[ ]]>块内的内容，将其列为需要人工复核的重点。

4.3 常见漏洞代码模式速查表

下表总结了几种典型的漏洞模式和安全写法，方便你快速对照排查：

漏洞场景	危险代码示例	安全代码示例	关键原因
JDBC 直接拼接	`String sql = "SELECT * FROM user WHERE id=" + request.getParameter("id");` `stmt.executeQuery(sql);`	`String sql = "SELECT * FROM user WHERE id=?";` `PreparedStatement ps = conn.prepareStatement(sql);` `ps.setInt(1, Integer.parseInt(id));`	用户输入直接成为SQL语法的一部分。
MyBatis 错误使用${}	`<select id="query" resultType="User">` `SELECT * FROM user ORDER BY ${orderBy} </select>`	1.首选：固定排序字段或白名单校验。 2.若必须动态：在Java代码中对`orderBy`参数进行严格白名单校验（如只允许`"id"`,`"name"`）。	`${}`是字符串替换，非参数化。
Like语句拼接	`sql += " AND name LIKE '%" + name + "%'";`	`sql += " AND name LIKE ?";` `ps.setString(paramIndex, "%" + name + "%");`	拼接在预编译语句创建之后，绕过了参数化。
IN语句拼接	`String sql = "SELECT * FROM goods WHERE id IN (" + ids + ")";`	动态生成占位符：`IN (?,?,?)`，或使用MyBatis的`<foreach>`标签。	同直接拼接。
Order By 动态排序	`String sql = "SELECT * FROM t ORDER BY " + sortField;`	对`sortField`进行白名单校验，只允许预定义的字段名。	`ORDER BY`后接的列名不能参数化，必须校验。

4.4 二次注入：一个容易被忽略的角落

这是一种更隐蔽的注入方式。攻击者将恶意数据（如包含SQL片段的用户名）通过正常的插入操作存入数据库。由于插入时可能使用了参数化查询，所以这一步是安全的。但后来，当另一个功能（如查询、更新）从数据库中取出这个“脏数据”，并在没有参数化的情况下将其拼接到新的SQL语句中时，注入就发生了。

漏洞模拟：

用户注册时，用户名为admin' --（注意末尾有空格）。应用使用参数化插入：INSERT INTO users(username) VALUES (?)，成功存入。
后台有一个“重置管理员密码”的功能，其SQL为：UPDATE users SET password='newPass' WHERE username='" + username + "'。这里错误地使用了拼接。
当从数据库取出用户名admin' --并拼接后，SQL变为：UPDATE users SET password='newPass' WHERE username='admin' -- '。--注释掉了后面的单引号，导致条件变为username='admin'，从而重置了管理员密码。

防御方法：对所有从数据库取出的、将要重新参与SQL拼接的数据，保持同样的警惕性，坚持使用参数化查询。同时，在数据存储前进行适当的过滤和转义（虽然主要防御不依赖此），也能增加攻击难度。

5. 从开发到部署：全流程安全 checklist

将安全左移，融入到软件开发生命周期的每一个环节，才是最有效的防御。

5.1 开发阶段

团队规范：制定并强制执行《SQL编写安全规范》，明确要求所有数据库操作必须使用参数化查询（PreparedStatement或ORM框架的参数绑定）。
代码模板：在IDE中创建PreparedStatement和MyBatis#{}的代码片段模板，方便开发人员取用。
结对编程与Review：在代码审查（Code Review）中，将SQL语句作为必审项。重点检查是否有字符串拼接、是否有${}的不当使用。
单元测试：编写包含各种边界值和恶意输入（如',;,--,1=1）的单元测试，确保DAO层方法能正确处理这些输入，或抛出预期的业务异常，而不是产生不可控的SQL错误。

5.2 测试阶段

渗透测试：邀请安全团队或使用自动化渗透测试工具（如sqlmap、Burp Suite Scanner）对应用进行黑盒/灰盒测试，模拟攻击者行为寻找注入点。
DAST工具扫描：使用动态应用安全测试（DAST）工具对运行中的应用进行扫描。
依赖项检查：使用OWASP Dependency-Check等工具检查项目依赖的第三方库（如数据库驱动、连接池、ORM框架）是否存在已知的SQL注入相关漏洞。

5.3 部署与运维阶段

数据库权限收紧：严格按照最小权限原则配置生产数据库账号。
WAF部署：在应用服务器前部署WAF，配置SQL注入防护规则。
日志审计：开启数据库的审计日志，监控异常的大量数据查询、非业务时间段的敏感表访问等行为。
应急预案：制定安全事件应急预案。一旦疑似发生SQL注入攻击，能快速定位日志、暂时封禁IP、评估数据泄露范围并进行修复。

解决SQL注入，技术上并不复杂，难的是将安全的意识变成一种肌肉记忆，贯穿于每一次敲击键盘的过程中。它不像算法优化那样能立刻提升性能，也不像新框架那样炫酷，但它却是系统稳定运行的基石。每次写完一个DAO方法，都花两秒钟问自己一句：“我这里的参数，都绑定了吗？” 这个简单的习惯，或许就能在未来的某一天，帮你挡住一次致命的数据危机。安全无小事，它始于每一行看似平凡的代码。