1. 项目概述从一次真实的线上事故说起去年我参与了一个电商项目的应急响应。凌晨两点监控系统报警数据库CPU瞬间飙到100%紧接着大量用户反馈订单信息错乱。我们紧急排查发现是一个看似无害的商品搜索接口被恶意利用攻击者通过精心构造的请求参数绕过了所有前端校验直接在数据库里执行了UNION SELECT查询拖走了整张用户表。根本原因一个资深开发在拼接WHERE子句时图省事直接用了字符串拼接。这个事故让我深刻意识到无论框架多么先进只要有一行代码的疏忽整个应用的安全防线就可能形同虚设。这就是代码审计的价值所在——它不是找茬而是在攻击者之前亲手把自家篱笆扎牢。今天要聊的就是Java应用中最高发、也最危险的漏洞之一SQL注入。很多人觉得用了MyBatis、JPA或者参数化查询就高枕无忧了。但现实是错误的使用方式、历史遗留代码、甚至是框架本身的特性都可能埋下隐患。这篇文章我将以一个实战者的视角带你深入Java应用的肌理手把手拆解如何系统性地发现SQL注入漏洞。无论你是安全工程师、开发人员还是架构师掌握这套方法都能让你在代码层面构筑起更坚固的防线。2. 核心原理为什么字符串拼接是万恶之源要发现漏洞必须先理解漏洞产生的根源。SQL注入的本质是程序将用户输入的数据当作代码的一部分送入了数据库解释器执行。在Java中最常见的诱因就是字符串拼接。2.1 从一段典型漏洞代码讲起假设我们有一个根据用户ID查询信息的DAO方法public User getUserById(String userId) { String sql SELECT * FROM users WHERE id userId ; // 执行查询... return jdbcTemplate.queryForObject(sql, User.class); }这段代码看起来清晰明了。但如果userId参数来自前端请求且攻击者传入的值是1 OR 11会发生什么拼接后的SQL语句变成了SELECT * FROM users WHERE id 1 OR 11WHERE条件变成了永真这意味着查询将返回users表中的所有记录。这只是一个开始更危险的payload可能是1; DROP TABLE users; --。在支持多语句执行的数据库驱动配置下这可能导致灾难性的数据丢失。注意这里的关键在于单引号闭合了原本的字符串字面量使得后续输入被“提升”为SQL语法的一部分。--是SQL中的单行注释符用于注释掉原语句后续可能存在的其他字符如另一个单引号确保攻击语句的完整性。2.2 深层解析编译与执行的分离数据库处理SQL语句分为两步编译解析与优化和执行。参数化查询PreparedStatement的核心优势在于它将这两个步骤清晰地分开了。字符串拼接方式SQL语句在程序运行时动态生成然后整个字符串被送到数据库。数据库需要每次都对全新的语句进行编译。用户输入的数据如果包含SQL关键字就会在编译阶段被误认为是语法的一部分。参数化查询方式SQL语句的模板如SELECT * FROM users WHERE id ?会先被发送到数据库进行编译。此时数据库已经知道这是一个查询语句?是一个占位符期待一个id字段的值。之后程序再将具体的参数值如userId单独发送给数据库执行。因为编译阶段已经完成此时传入的数据无论是什么都只会被当作纯粹的数据值来处理不可能改变语句的语法结构。一个生活化的比喻这就像点一份定制披萨。字符串拼接你告诉厨师“做一个披萨加上番茄、芝士和隔壁桌客人递过来的东西”。厨师照单全收如果隔壁递过来的是“和一把螺丝刀”后果可想而知。参数化查询你使用标准的点菜单模板在“额外配料”一栏占位符写下“菠萝”。厨师先看菜单知道你要一个定制披萨然后去食材区拿“菠萝”这个具体的食材。隔壁客人即使递过来“螺丝刀”因为点菜单上没有这个选项厨师根本不会理会。理解了这个根本区别我们审计时就有了第一把标尺凡是看到SQL语句中有通过或String.format()等方式直接将变量拼接到字符串中的都需要立刻亮起红灯。3. 审计实战四大高危场景深度剖析知道了原理我们开始实战。Java生态庞大SQL注入可能藏匿在各个环节。我将其归纳为四个最需要重点审查的高危场景。3.1 场景一原生JDBC与“错误的正确用法”很多人认为用了PreparedStatement就绝对安全这是一个误区。漏洞模式1伪参数化查询String sql SELECT * FROM users WHERE id userId; // 数值型拼接看似没问题 PreparedStatement stmt connection.prepareStatement(sql); ResultSet rs stmt.executeQuery();这里虽然创建了PreparedStatement对象但SQL语句在传入prepareStatement方法之前就已经拼接完毕了。PreparedStatement的预编译机制完全没起作用。审计时必须确认SQL字符串在传入prepareStatement或JdbcTemplate等方法时是完整的、带有占位符的模板。漏洞模式2动态排序与表名/列名拼接String orderBy request.getParameter(orderBy); // 用户传入username; DROP TABLE logs String sql SELECT * FROM logs ORDER BY orderBy;ORDER BY、GROUP BY后面跟的字段名以及SELECT后的表名都不能使用?占位符。这是SQL语法限制。对于此类需求必须采用白名单校验。// 正确的做法白名单校验 ListString allowedColumns Arrays.asList(id, time, level); String orderBy request.getParameter(orderBy); if (!allowedColumns.contains(orderBy)) { orderBy id; // 默认值 } String sql SELECT * FROM logs ORDER BY orderBy;3.2 场景二MyBatis框架下的“安全盲区”MyBatis因其灵活性备受青睐但灵活性也带来了风险。风险点1${}与#{}的混淆这是MyBatis审计的重中之重。#{}是安全的参数占位符MyBatis会将其转换为PreparedStatement的?并安全地设置参数。${}是字符串替换文本替换。MyBatis会将参数值直接拼接到SQL语句中存在SQL注入风险。审计时全局搜索\${每一个都需要仔细审查其使用场景。通常${}仅能用于动态指定表名、列名等无法使用占位符的场景且必须结合白名单。!-- 高危直接拼接用户输入 -- select idselectUser parameterTypeString resultTypeUser SELECT * FROM users WHERE username LIKE %${name}% /select !-- 安全使用#{} -- select idselectUser parameterTypeString resultTypeUser SELECT * FROM users WHERE username LIKE CONCAT(%, #{name}, %) /select风险点2动态SQL标签的误用在if,choose,foreach等标签内也应坚持使用#{}。!-- 错误示例 -- select idfindActiveUser parameterTypeString resultTypeUser SELECT * FROM users WHERE 11 if testusername ! null AND username ${username} !-- 这里用了${}危险 -- /if /select3.3 场景三JPA/Hibernate中的原生SQL与HQL/JPQL注入ORM框架旨在避免手写SQL但有时开发者会使用原生SQL以获得更高灵活性或性能。风险点1原生SQL查询createNativeQueryString userInput request.getParameter(name); // 高危字符串拼接 Query query em.createNativeQuery(SELECT * FROM User u WHERE u.name userInput ); // 安全使用参数化 Query safeQuery em.createNativeQuery(SELECT * FROM User u WHERE u.name ?1); safeQuery.setParameter(1, userInput);审计时关注EntityManager.createNativeQuery(String sql)和Session.createSQLQuery(String sql)的调用检查传入的sql字符串是否被拼接。风险点2HQL/JPQL注入HQL/JPQL本身是面向对象的查询语言但拼接参数同样危险。// 高危HQL拼接 String hql FROM User WHERE name userInput ; Query query session.createQuery(hql); // 安全使用命名参数或位置参数 String safeHql FROM User WHERE name :userName; Query safeQuery session.createQuery(safeHql); safeQuery.setParameter(userName, userInput);虽然HQL注入不能直接执行数据库管理命令如DROP TABLE但可以导致数据泄露、逻辑绕过等严重后果。3.4 场景四被忽略的“边角”与第三方库漏洞往往藏在盲区。IN子句的动态拼接这是一个经典难题。当需要查询id在某个可变列表中的记录时容易犯错。// 错误做法拼接字符串 String ids 1,2,3; // 假设来自用户输入1,2,3) OR 11 -- String sql SELECT * FROM items WHERE id IN ( ids );正确做法使用MyBatis的foreach标签或手动生成多个占位符?并循环设置参数。// JdbcTemplate示例 String sql SELECT * FROM items WHERE id IN (:ids); MapSqlParameterSource params new MapSqlParameterSource(); params.addValue(ids, Arrays.asList(idArray)); // 传入List namedParameterJdbcTemplate.query(sql, params, rowMapper);模糊查询LIKE如前所述避免使用%${value}%应使用CONCAT(%, #{value}, %)或数据库特定的函数如MySQL的CONCAT。第三方查询构建器如QueryDSL、JOOQ等。它们通常能生成参数化查询但需要审计其使用模式确保没有调用其底层可能暴露的字符串拼接方法。XML配置文件中的SQL除了MyBatis的Mapper XML一些老旧系统或自研框架可能会将SQL语句写在独立的XML配置文件中并通过字符串替换加载。审计时需要检查这些文件的加载和解析逻辑。4. 审计工具箱方法与技巧有了目标我们还需要趁手的工具和方法。代码审计不是漫无目的地“看代码”而是一场有策略的狩猎。4.1 静态代码分析SAST工具辅助人工审计效率低需要工具先行扫描定位可疑点。商业/开源工具SonarQube、Fortify SCA、Checkmarx等。它们内置了丰富的安全规则能快速扫描出潜在的SQL注入点。例如它们能识别出StringBuilder拼接SQL字符串后直接执行的情况。关键点不要完全依赖工具的扫描结果。工具会产生误报将安全的代码报为漏洞和漏报未能发现真正的漏洞。审计的核心是对工具报告的可疑点进行人工确认和上下文分析。4.2 人工审计的“搜捕”策略工具扫一遍后就要开始人工精审。我常用的搜索关键词和策略如下关键词全局搜索在IDE或代码仓库中全局搜索以下模式Statement(特别是createStatement)executeQueryexecuteUpdateexecute.(拼接字符串的加号配合正则)String.format.*sql(格式化字符串拼接SQL)StringBuilder.*sql/StringBuffer.*sqlappend.*sql\$\{(MyBatis危险符号)跟踪数据流找到一个可疑的拼接点后不要停留。向上追踪这个危险参数的来源。它可能来自HttpServletRequest.getParameter()RequestParam、PathVariable(Spring MVC)RPC接口参数读取的文件内容数据库查询结果二次注入的源头 一直追溯到该参数的源头确认整个传递路径上是否有任何过滤或校验。检查过滤器与拦截器很多项目会在全局层面通过Filter或Interceptor对参数进行过滤如转义单引号。需要确认过滤规则是否完备是否只过滤了没过滤\是否有路径漏过了过滤警惕“过度依赖”绝不能因为有了全局过滤器就认为代码层是安全的。安全防御需要层层设防。4.3 动态测试验证静态分析可能存在盲区需要结合动态测试。构造测试用例对于审计出的可疑接口使用Burp Suite、Postman等工具手动构造测试Payload。基础探测在参数后添加单引号观察返回错误信息如MySQL错误、JDBC异常等。错误信息可能泄露数据库类型、表结构等。布尔盲注测试输入1 AND 11和1 AND 12观察应用返回结果是否不同真/假条件导致页面内容差异。时间盲注测试输入1 AND SLEEP(5)--观察响应时间是否明显延迟。灰盒测试如果条件允许在测试环境部署应用并开启数据库的通用日志或慢查询日志。执行测试Payload时直接观察数据库实际接收和执行的SQL语句这是最直接的验证方式。5. 深入排查进阶漏洞与隐蔽技巧当常见的漏洞模式都被排除后一些更隐蔽、更高级的注入点就需要我们拿出“放大镜”了。5.1 二次注入潜伏的杀手这是最容易被忽略的类型之一。攻击者输入的数据第一次被存入数据库时是安全的可能经过了转义或参数化查询。但当这些数据被从数据库中取出未经再次检验就拼接到新的SQL语句中时漏洞就触发了。审计案例用户注册时用户名admin--被存入数据库。由于注册逻辑使用了参数化查询存入的就是字符串admin--。后台有一个“管理员重置用户密码”的功能其SQL可能是拼接而成的String sql UPDATE users SET passworddefaultPassword WHERE usernameusernameFromDb;当从数据库取出用户名admin--并拼接到上述SQL中时语句变为UPDATE users SET password123456 WHERE usernameadmin----注释掉了后面的单引号导致条件变为WHERE usernameadmin从而重置了管理员密码。审计方法重点关注“数据从数据库读出 - 再次参与SQL拼接”的流程。特别是那些用于“管理”、“批量操作”、“数据同步”的后台功能。5.2 框架特性与配置陷阱MyBatislike拼接的另一种错误即使使用了#{}也可能出错。select idfind parameterTypeString resultTypeBlog SELECT * FROM blog WHERE title like %#{title}% /select这样写MyBatis会报错因为#{}在解析后会被替换成?最终SQL变成like %?%语法错误。这会让开发者“被迫”转向错误的${}解决方案。正确的做法如前所述使用CONCAT函数。JPA的Query注解中的原生SQLQuery(value SELECT * FROM user u WHERE u.email ?1, nativeQuery true) User findByEmailAddress(String email);使用?1位置参数是安全的。但如果看到注解中的SQL字符串有拼接痕迹如号则是高危信号。数据库连接池配置某些旧的或配置不当的连接池如DBCP可能允许在连接URL中设置参数如allowMultiQueriestrueMySQL。这会使数据库允许一次执行多条SQL语句极大增加了注入攻击的危害性如通过;执行多条语句。审计时需检查JDBC连接字符串的配置。5.3 存储过程与函数调用如果应用调用了数据库存储过程或函数并且参数是动态拼接的同样存在风险。String sql {call get_user_data( input )};审计时需搜索{call和{? call等调用存储过程的关键字。6. 修复方案与最佳实践发现漏洞只是第一步给出明确、可操作的修复方案才是审计的最终目的。6.1 根本解决方案使用参数化查询这是唯一被OWASP等权威组织推荐为根本解决方案的方法。JDBC无条件使用PreparedStatement并确保SQL字符串在创建PreparedStatement对象时是完整的模板。Spring JdbcTemplate使用带?占位符的SQL配合update(String sql, Object... args)或query(String sql, Object[] args, RowMapperT rowMapper)方法。对于命名参数使用NamedParameterJdbcTemplate。MyBatis99%的情况下使用#{}。仅在动态表名/列名等场景下经过严格白名单校验后方可谨慎使用${}。JPA/Hibernate使用Query.setParameter()或命名参数:name来绑定参数。6.2 辅助防御输入验证与输出编码输入验证白名单对于已知固定范围的数据如状态枚举、排序字段使用白名单校验。private static final SetString ALLOWED_SORT_FIELDS Set.of(createTime, price); public String validateSortField(String input) { return ALLOWED_SORT_FIELDS.contains(input) ? input : createTime; }最小化数据库权限应用连接数据库的账号应遵循最小权限原则。只授予其业务必需的最小的INSERT、SELECT、UPDATE、DELETE权限绝对不要使用DBA或拥有DROP、CREATE、ALTER等管理权限的账号。这样即使发生注入危害也被限制在特定数据范围内。6.3 MyBatis安全编码规范示例为团队制定明确的规范至关重要。场景错误示例正确示例说明条件查询username ${name}username #{name}核心原则模糊查询title LIKE %${keyword}%title LIKE CONCAT(%, #{keyword}, %)使用数据库函数或bind标签IN 查询id IN (${ids})使用foreach标签foreach itemid collectionids open( separator, close)#{id}/foreach动态排序ORDER BY ${orderBy}白名单校验后拼接代码层校验或使用choose枚举所有合法排序字段6.4 使用更安全的工具库考虑使用设计上更安全的查询构建器例如JOOQ它通过DSL领域特定语言生成SQL其API设计几乎杜绝了字符串拼接的可能。Spring Data JPA尽可能使用其方法名派生查询或Query注解使用JPQL和参数绑定避免手写原生SQL。QueryDSL类似JOOQ提供类型安全的查询方式。7. 常见问题与排查技巧实录在实际审计和修复过程中你会遇到各种奇怪的问题。这里记录几个我踩过的坑和解决技巧。问题1MyBatis中#{}在IN语句里报错现象在IN子句中直接写id IN (#{ids})传入一个ListMyBatis会报语法错误。原因MyBatis会将#{ids}替换成单个?而数据库期望的是IN (?, ?, ?)这样的多个占位符。解决必须使用foreach标签动态生成占位符。这是MyBatis处理动态IN查询的唯一正确方式。问题2日志里看到的SQL参数都是?怎么确认执行了注入技巧开启MyBatis的完整SQL日志。在配置文件中设置logImpl为STDOUT_LOGGING并在日志框架配置中将mapper接口的日志级别设为DEBUG。这样可以看到运行时替换了真实参数的完整SQL语句便于调试和验证。问题3全局过滤器转义了单引号为什么还有风险案例过滤器将转义为\。对于MySQL这通常是安全的。但如果数据库是Oracle其转义符是两个单引号。如果过滤器只按MySQL规则处理而应用实际连接Oracle则防御失效。教训不要依赖单一的、应用层的通用转义。转义规则与数据库类型强相关且可能存在绕过手段如编码绕过。参数化查询是与数据库无关的、根本的解决方案。问题4审计一个庞大历史项目无从下手策略采用“风险优先”策略。先扫入口用SAST工具快速扫描全项目按严重等级排序。聚焦核心人工优先审计与用户输入直接相关的模块如登录、搜索、订单处理、后台管理。追踪资金流在金融、电商项目中优先审计涉及账户、支付、余额变动的所有SQL操作。检查“工具类”很多项目会有自封装的DBHelper、SqlUtil类这些类如果设计不当会成为漏洞的重灾区需要重点审查其核心执行方法。问题5开发不认同这是高危漏洞认为有WAFWeb应用防火墙就够了沟通话术WAF是重要的边界防护但安全防御需要纵深。代码层漏洞是根源WAF规则可能被绕过如编码变形、慢速攻击。修复代码漏洞是“治本”能降低对WAF的依赖提升应用自身免疫力也符合安全左移的原则。从成本上看一次代码修复的成本远低于漏洞被利用后导致的数据泄露事故带来的品牌声誉损失和合规罚款。