PreparedStatement：参数化查询的底层逻辑与避坑指南
很多人以为PreparedStatement防注入就是”用setString代替字符串拼接”这么简单，其实这里面藏着不少门道。我见过最离谱的代码是：用PreparedStatement创建对象，却在SQL语句里直接拼接用户输入，比如"SELECT FROM user WHERE username = '" + request.getParameter("name") + "'"——这种写法比不用PreparedStatement还危险，因为它会让你误以为代码很安全，放松警惕。
为什么参数化查询能防注入？
你可以把SQL执行过程想象成”点餐”：非参数化查询就像你直接告诉厨师”来份宫保鸡丁不要辣多放花生再加把火点了厨房”，厨师可能真的会执行后面的危险操作；而参数化查询则是先把菜单（SQL结构）交给厨师，比如”来份宫保鸡丁，辣度：？，配料：？”，然后单独把”不要辣””多放花生”这些参数递给服务员，厨师只会按固定菜单做菜，不会把参数当成新的”点火”指令。
具体来说，PreparedStatement会在数据库端先进行SQL预编译，把SELECT FROM user WHERE username = ?这种固定结构的语句编译成执行计划，此时SQL的语法结构已经固定，后续传入的参数（比如用户输入的字符串）只会被当成数据处理，不会被数据库解析为SQL命令。这就是为什么即使参数里有' OR '1'='1这种恶意代码，数据库也只会把它当成普通的字符串去匹配username字段，而不是执行”恒真条件”的查询。
90%的人会踩的三个坑点
别以为用了PreparedStatement就万事大吉，我审计过的项目里，至少一半的”防注入代码”都存在这些问题：
第一个坑：参数化不彻底
最常见的错误是只对部分参数用setXxx方法，另一部分偷偷拼接。比如这段代码：
String sql = "SELECT FROM product WHERE category = '" + category + "' AND price < ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, maxPrice);
这里category参数还是用字符串拼接，假如用户传入' OR '1'='1; DROP TABLE product; ，整个SQL就会变成恶意语句。记住：所有用户输入的变量，不管看起来多”安全”，都必须用参数化传递，包括搜索关键词、排序字段、分页参数等。
第二个坑：错误使用setObject方法
有些开发者图省事，不管参数类型全用setObject，比如pstmt.setObject(1, userId)。如果userId是整数类型还好，但如果是字符串，可能会因为数据库字符集转换问题导致参数被截断或转义失效。我 你按参数实际类型选择setXxx方法：字符串用setString，数字用setInt/setLong，日期用setTimestamp，这样能让数据库更准确地处理参数，也能避免类型转换时的安全隐患。
第三个坑：预编译语句被缓存覆盖
JDBC默认会缓存PreparedStatement对象提高性能，但如果你的代码在循环里动态修改SQL结构，可能会导致缓存的预编译语句被覆盖。比如在for循环里根据不同条件拼接SQL字符串，再创建PreparedStatement——这种情况下预编译机制会失效，相当于每次都执行普通Statement。正确的做法是把固定结构的SQL提到循环外，只在循环内设置不同参数，比如：
// 错误：循环内拼接SQL，预编译失效
for (String name nameList) {
String sql = "SELECT FROM user WHERE name = '" + name + "'"; // 这里拼接已经错了！
PreparedStatement pstmt = conn.prepareStatement(sql);
}
// 正确：循环外定义SQL，循环内设置参数
String sql = "SELECT * FROM user WHERE name = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
for (String name nameList) {
pstmt.setString(1, name);
pstmt.executeQuery();
}
MyBatis/Hibernate防注入实战：从#{}到动态SQL的安全写法
“用了ORM框架就不用操心SQL注入了”——这是我听过最多的误解。去年帮一个金融项目做渗透测试时，我们仅用一行order by id desc; DROP TABLE log; 就绕过了他们的MyBatis防御，因为他们在动态排序时用了${}语法。ORM框架确实能帮我们处理大部分参数，但如果不懂它的底层逻辑，反而会踩更深的坑。
MyBatis中#{}和${}的”生死区别”
MyBatis的防注入能力几乎全靠#{}和${}的使用区别，但很多人直到项目被攻击了都没搞清楚这两个符号的本质。简单说：#{}会把参数当成”数据”处理，自动添加引号并转义；${}则会把参数直接拼接到SQL语句中，相当于字符串拼接。我做了个表格帮你直观对比：
| 语法 | 处理方式 | 安全级别 | 适用场景 |
|---|---|---|---|
| #{username} | 参数化处理，自动加引号转义 | 高（防注入） | 查询条件、插入值、更新字段值 |
| ${orderField} | 直接字符串替换，无转义 | 低（可能注入） | 排序字段、表名（需严格过滤） |
最容易踩坑的场景是动态排序和分表查询
。比如前端传sort=price desc; DROP TABLE product; ，如果你用ORDER BY ${sort}，整个SQL就会变成灾难。这时候不能直接用${}，也不能硬改成#{}（因为排序字段不需要引号，#{}会自动加引号导致SQL语法错误）。正确的做法是用白名单过滤：提前定义允许的排序字段列表，比如List allowFields = Arrays.asList("price", "create_time", "id");，收到前端参数后先检查是否在白名单内，不在就用默认字段排序。我之前帮电商项目处理这个问题时，就是这么做的，既安全又不影响功能。
Hibernate的HQL注入：比SQL注入更隐蔽的陷阱
Hibernate用户可能觉得”用HQL就不会有注入”，但OWASP官网早就指出：HQL注入和SQL注入原理类似，都是因为用户输入被当成HQL命令执行。比如这段HQL代码：
String hql = "FROM User u WHERE u.username = '" + username + "'";
Query query = session.createQuery(hql);
如果username是' OR '1'='1，HQL会查询出所有用户数据。和JDBC一样，Hibernate的防注入核心也是参数化查询，正确写法是用setParameter方法：
String hql = "FROM User u WHERE u.username = username";
Query query = session.createQuery(hql);
query.setParameter("username", username); // 参数化传递，安全
还有个容易被忽略的点：Hibernate的createSQLQuery方法会直接执行原生SQL，如果用字符串拼接参数，和普通JDBC的Statement一样危险。我见过有团队为了性能用原生SQL，结果忘了参数化，导致比HQL注入更严重的后果。记住：不管用HQL还是原生SQL，只要有用户输入参与查询，就必须参数化。
你在实际开发中可能还会遇到”动态拼接HQL”的需求，比如多条件搜索时根据用户输入动态添加WHERE子句。这时候可以用Hibernate的Criteria API，它会自动帮你处理参数化，比手动拼接HQL安全得多。比如：
Criteria criteria = session.createCriteria(User.class);
if (StringUtils.isNotBlank(username)) {
criteria.add(Restrictions.eq("username", username)); // 自动参数化，安全
}
if (minAge != null) {
criteria.add(Restrictions.ge("age", minAge));
}
这种写法既灵活又安全，我 你优先用Criteria API处理动态查询场景。
其实SQL注入防御说难也不难，核心就是”让用户输入只做数据，不做命令”。你不用死记硬背那么多理论，记住三个原则就行：所有用户输入必须参数化、少用字符串拼接SQL、定期用代码扫描工具（比如SonarQube）检查项目。我之前带团队时，每周都会花半小时审查新写的数据库操作代码，虽然麻烦，但这几年确实没再出过注入相关的安全事故。
如果你按这些方法优化了代码，或者之前踩过类似的坑，欢迎在评论区告诉我你的经历——毕竟安全这事儿，多交流才能少踩坑嘛！
你肯定会想：“就一个用户输入的小参数，比如商品分类或者页码，我直接拼接一下能省不少事，应该没事吧？”这话我去年听一个刚入行的同事说过，结果他负责的商品搜索接口上线三天就被注入攻击了——当时他只对价格参数用了setInt，觉得分类参数“都是后台定义好的选项，用户改不了”，就直接拼接了"WHERE category = '" + category + "' AND price < ?"。结果攻击者通过抓包修改了category参数，传了一串' OR 1=1; DROP TABLE product; ，要不是数据库用的只读账号，整个商品表可能都没了。
真不是我危言耸听，SQL注入这东西就像千里之堤上的蚁穴，只要有一个参数没做好参数化，就等于给攻击者留了个突破口。你想想，就算99个参数都用了setString、setInt，就那1个偷懒拼接的，可能就是压垮系统的最后一根稻草。我之前帮金融项目做代码审计时，见过更离谱的：有人在分页查询里拼接页码，觉得“页码就是数字，能有什么问题？”结果攻击者传了个1; DELETE FROM user; ，要不是数据库开了事务日志，客户的用户数据差点就找不回来了。所以不管参数看起来多“安全”，只要是用户能接触到的输入——哪怕是下拉框里的选项、隐藏字段的值——都必须老老实实走setXxx方法，别抱任何侥幸心理。
使用PreparedStatement时，是否所有用户输入的参数都必须通过setXxx方法传递？
是的，所有用户输入的参数（包括搜索关键词、分页参数、排序字段等）都必须通过setXxx方法（如setString、setInt）参数化传递，绝对不能对任何用户输入进行字符串拼接。文章中提到的“参数化不彻底”是常见坑点——哪怕只有一个参数用拼接，就可能埋下注入隐患。比如仅对价格参数用setInt，却拼接分类参数，攻击者仍能通过分类参数注入恶意代码。
MyBatis中#{}和${}有什么本质区别？动态排序场景该如何安全使用${}？
#{}会将参数视为“数据”，自动进行参数化处理（预编译+转义），能有效防注入；而${}会直接将参数拼接到SQL中，相当于字符串替换，存在注入风险。动态排序场景（如按价格、时间排序）不能直接用${}，也不能硬改#{}（#{}会给字段加引号导致语法错误），需用白名单过滤：提前定义允许的排序字段（如price、create_time），检查前端传入的字段是否在白名单内，不在则用默认字段排序，这是文章中验证有效的安全方案。
Hibernate的HQL查询会出现注入风险吗？如何避免？
会。HQL注入与SQL注入原理类似，若用字符串拼接用户输入到HQL中（如”FROM User u WHERE u.username = ‘” + username + “‘”），攻击者可通过输入’ OR ‘1’=’1获取所有数据。避免方法和JDBC一致：使用参数化查询，通过query.setParameter(“username”, username)传递参数，让Hibernate自动处理参数转义和预编译，杜绝拼接风险。
如何快速验证项目中是否存在SQL注入漏洞？
可通过“输入测试+代码审计”结合验证：先用常见注入测试字符串（如’ OR ‘1’=’1、” OR “1”=”1、; DROP TABLE test; ）测试用户输入接口（如登录、搜索框），观察是否返回异常数据或报错；再审计代码，重点检查是否存在字符串拼接SQL、PreparedStatement未完全参数化、MyBatis中${}未过滤等问题。我之前帮项目做验证时，用这种方法2小时就发现了3处隐藏的注入隐患。
除了参数化查询，还有哪些措施能辅助防御SQL注入？
可从多层面加强防御：①输入验证：对用户输入进行格式校验（如手机号、邮箱用正则过滤特殊字符）；②最小权限原则：数据库账号仅授予必要权限（如查询用SELECT权限，禁止DROP、DELETE权限）；③使用安全框架：借助MyBatis-Plus的条件构造器、Spring Data JPA的参数化查询等，减少手动拼接；④定期安全审计：用SonarQube等工具扫描代码，结合OWASP Top 10漏洞清单检查注入风险，形成“参数化+多防线”的安全体系。
