Java代码审计实战：SQL注入漏洞挖掘与MyBatis安全编码规范

📅 2026/7/5 19:21:08 👁️ 阅读次数 📝 编程学习

1. 项目概述：从开发者到审计者的视角转变

做Java开发这么多年，从写第一行SELECT * FROM users开始，就知道SQL注入是个“老生常谈”的安全问题。但真正让我对它有切肤之痛的，不是看漏洞报告，而是几年前自己写的一个内部管理系统被白帽子“教育”了。那个项目里，一个简单的订单查询功能，因为图省事在ORDER BY后面直接拼接了用户传入的排序字段，导致被拖了库。从那时起，我才真正明白，“知道”和“在代码里避免”是两回事。这也是为什么后来我开始深入研究Java代码审计，尤其是SQL注入——我想知道，一个看似功能正常的Java Web应用，它的“血管”（数据流）里到底藏着多少我们亲手埋下的“雷”。

所谓Java代码审计中的SQL注入审计，本质上是一场“猫鼠游戏”。开发者在业务逻辑的驱动下，追求灵活与效率，可能会在动态SQL、排序、模糊查询等场景下使用字符串拼接。而审计者（或攻击者）则像侦探一样，沿着数据从HTTP请求进入，经过Controller、Service、Dao层，最终到达SQL语句的完整路径，寻找任何一处可能的拼接点，并判断其是否可控、是否被有效过滤。这个过程不仅需要熟悉Java Web的典型架构（如Spring Boot + MyBatis），更需要理解SQL注入在各种上下文（JDBC、Hibernate、JPA、MyBatis）下的不同表现形式。今天，我就结合自己踩过的坑和审过的项目，把这套方法论和实操细节系统地梳理一遍，目标是让你看完后，不仅能快速上手审计，更能从根本上理解如何写出更安全的代码。

2. SQL注入原理与Java中的典型脆弱点

要审计，先得知道漏洞是怎么产生的。SQL注入的核心原因就一句话：将用户可控的数据，未经充分验证或转义，直接拼接到了SQL语句中，改变了原语句的语义。在Java生态里，这个“拼接”动作发生在不同层次，形态各异。

2.1 不同持久层框架下的注入模式

JDBC原生拼接：这是最原始、也最容易被发现的类型。特征非常明显：代码中存在用加号（+）或StringBuilder拼接字符串来构造SQL的语句。

// 典型的错误示例：直接拼接 String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"; Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(sql);

这里，如果username传入admin' --，整个SQL语义就被篡改了，密码验证被注释掉。审计时，全局搜索createStatement()、executeQuery(、executeUpdate(，然后查看其执行的SQL字符串是否包含拼接变量。

MyBatis中的${}与#{}之辨：这是当前Java Web项目中最常见、也最隐蔽的注入点。MyBatis用#{}表示预编译占位符，用${}表示字符串替换。很多开发者，尤其是初学者，并不清楚两者的本质区别，甚至在官方文档不显眼的地方才有警告。

<!-- 安全：预编译，注入无效 --> <select id="findUser" parameterType="String" resultType="User"> SELECT * FROM user WHERE username = #{name} </select> <!-- 危险：直接替换，存在注入风险 --> <select id="findUser" parameterType="String" resultType="User"> SELECT * FROM user WHERE username = '${name}' </select>

#{name}在运行时会被替换成?，然后通过PreparedStatement.setString()等方法安全地设置参数值。而${name}则是在SQL解析阶段，直接进行字符串替换。如果name的值是admin' OR '1'='1，替换后SQL语法依然正确，但逻辑被绕过。审计MyBatis项目，核心就是全局搜索${，尤其是在Mapper XML文件中。

Hibernate与JPA的误区：很多人认为使用ORM框架就高枕无忧了，这是致命的误解。Hibernate的HQL（Hibernate Query Language）和JPA的JPQL（Java Persistence Query Language）如果使用字符串拼接，同样会导致注入，这类注入通常被称为“HQL注入”或“JPQL注入”。

// 错误：HQL拼接 String hql = "FROM User WHERE username = '" + username + "'"; Query query = session.createQuery(hql); // 正确：使用参数绑定 String hql = "FROM User WHERE username = :username"; Query query = session.createQuery(hql); query.setParameter("username", username);

ORM框架防止的是SQL注入，因为它最终生成的SQL是参数化的。但如果你拼接的是HQL/JPQL字符串，框架会将其完整地作为查询语言解析，攻击者同样可以注入HQL语句（例如通过' OR '1'='1绕过）。审计时需关注createQuery(、createNativeQuery(（原生SQL拼接风险更高）等方法调用。

2.2 那些容易被忽略的“合法”拼接场景

并不是所有使用${}或字符串拼接的地方都立刻判“死刑”。有些场景下，使用#{}会导致语法错误，迫使开发者使用${}，这就成了风险集中的高地。审计时需要特别关注以下四个高危场景：

动态表名/字段名：SQL语法不允许预编译占位符（?）出现在表名或字段名位置。SELECT * FROM #{tableName}预编译后会变成SELECT * FROM ?，执行时会报错。因此，当功能需要动态选择表或字段时，开发者往往被迫使用${}。这里的风险在于，如果tableName参数用户可控（比如通过前端下拉框传入，但被恶意篡改），就可能注入UNION SELECT等子句。
ORDER BY / GROUP BY 子句：与表名类似，ORDER BY #{field}会被编译为ORDER BY 'field'，导致按字符串常量排序，而非按字段排序，不符合预期。因此，动态排序功能常使用ORDER BY ${sortField} ${sortOrder}。如果sorField可控，攻击者可以传入id,(SELECT SLEEP(5))这类语句进行盲注。
LIKE 模糊查询：这是一个经典误区。有人尝试LIKE '%#{keyword}%'，但预编译后是LIKE '%?%'，数据库会将?连同百分号一起视为一个字符串参数，导致查询失败。错误的做法是使用LIKE '%${keyword}%'，这就敞开了注入的大门。正确的做法是在SQL中使用数据库的字符串连接函数配合#{}，如MyBatis中：LIKE CONCAT('%', #{keyword}, '%')。
IN 语句：直接写IN (#{ids})是不行的，因为预编译期望一个参数，但你传入的是一个列表。MyBatis提供了<foreach>标签来安全处理，但有些开发者会错误地拼接字符串：IN (${idList})，如果idList来自用户输入（如1,2,3) OR 1=1 --），注入就产生了。

注意：审计时看到这些场景使用了${}，要立刻提高警惕。但这只是第一步，关键还要看这个${}中的参数来源是否用户可控、是否被严格过滤或白名单校验。

3. 代码审计实战：四步定位SQL注入漏洞

理论清楚了，我们进入实战。假设拿到一个Spring Boot + MyBatis的项目代码，如何系统性地进行SQL注入审计？我总结为“四步定位法”。

3.1 第一步：全局扫描，锁定可疑点

工具先行，提高效率。可以使用grep、find命令，或者IDE的全局搜索功能（IntelliJ IDEA的Ctrl+Shift+F非常强大）。

搜索关键词清单：

XML文件（MyBatis Mapper）：\$\{。这是最高效的方式，能直接定位到MyBatis中所有字符串替换点。
Java代码中的SQL字符串：\.executeQuery\(、\.executeUpdate\(、\.createStatement\(、\+.*['"]（粗糙但广泛）、StringBuilder.*append.*SELECT、"SELECT.*\+"。
Hibernate/JPA：createQuery\(.*\+、createNativeQuery\(.*\+。
注解形式SQL（MyBatis @Select等）：同样搜索\$\{，因为注解中也可以使用。

例如，在项目根目录下执行：

# 查找所有Mapper XML中的${} find . -name "*.xml" -type f | xargs grep -l "\${" | grep -i mapper # 查找Java代码中的字符串拼接SQL find . -name "*.java" -type f | xargs grep -n "\.executeQuery\("

3.2 第二步：逆向追踪，绘制数据流图

找到可疑点（比如一个${keyword}）后，这只是漏洞的“终点”。我们需要逆向追踪，找到这个参数的“起点”，即它从哪里来。这个过程就像侦探破案，追踪资金的流向。

以MyBatis Mapper为例，标准追踪路径是：Mapper XML->Mapper Interface->Service Impl->Controller->HTTP Request

从Mapper XML开始：假设在UserMapper.xml中发现SELECT * FROM user WHERE name LIKE '%${name}%'。
找到对应的Mapper接口：查看XML文件头部的namespace，如com.example.dao.UserMapper。找到该Java接口，里面会有一个方法名与XML中select的id对应，例如List<User> findUsersByName(String name);。
找到Service层调用：在IDE中，右键点击这个findUsersByName方法，选择“Find Usages”（查找引用）。通常会跳转到UserServiceImpl类中的一个方法。
分析Service方法：查看该Service方法的实现。参数name是从哪里来的？可能是直接传入，也可能是从某个DTO对象中获取。继续向上追踪。
找到Controller层：再次使用“Find Usages”查找该Service方法的调用处，最终会定位到某个@RestController或@Controller中的方法，该方法通常带有@GetMapping、@PostMapping等注解。
确认参数来源：查看Controller方法的参数。它可能使用了@RequestParam("keyword") String keyword或@RequestBody UserQueryDTO dto。至此，你确认了参数name最终来源于用户HTTP请求。

追踪过程中的关键判断点：

参数类型：如果Mapper中${}对应的接口方法参数是int、Integer、Long等数字类型，风险相对较低（但仍需警惕数字型注入，虽然罕见）。如果是String，风险陡增。
中间处理：在Service层或Controller层，是否对参数进行了过滤、转义或校验？例如，是否调用了StringEscapeUtils.escapeSql（注意：这个方法是不推荐用于防SQL注入的！它只为JDBC转义，并非万无一失）、是否使用了正则表达式过滤了单引号、分号等？过滤逻辑是否严谨，能否被绕过（如双写、编码绕过）？
全局过滤器/拦截器：查看项目是否有配置Filter、Interceptor或AOP切面，对请求参数进行全局的SQL注入过滤。例如，是否过滤了sleep、benchmark、union select等关键字。但要注意，这种黑名单方式很容易被绕过。

3.3 第三步：上下文分析，评估真实风险

并非所有拼接都意味着立即可利用的漏洞。需要结合上下文进行深度分析。

场景一：动态排序（ORDER BY）

<select id="findUsers" resultType="User"> SELECT * FROM user ORDER BY ${sortField} ${sortOrder} </select>

风险：极高。sortField和sortOrder通常直接来自前端排序控件。
审计：追踪sortField。如果前端固定传入id、name等字段名，且后端没有映射机制，攻击者可以修改请求，将sortField设置为id,(SELECT IF(SUBSTRING(database(),1,1)='a', SLEEP(5), 0))，即可进行基于时间的盲注。
安全方案：应使用白名单校验。在后端维护一个允许排序的字段列表，将前端传入的值与白名单比对，或用枚举限定。

// 安全做法：白名单映射 private static final Map<String, String> SORT_FIELD_WHITELIST = new HashMap<>(); static { SORT_FIELD_WHITELIST.put("createTime", "create_time"); SORT_FIELD_WHITELIST.put("userName", "username"); } String dbField = SORT_FIELD_WHITELIST.getOrDefault(userInputField, "id"); // 默认值 // 然后将dbField传入Mapper，此时使用${}风险可控，因为值已被限定

场景二：模糊查询（LIKE）

<select id="search" resultType="Item"> SELECT * FROM items WHERE title LIKE '%${keyword}%' </select>

风险：高。keyword直接来自搜索框。
审计：这是最常见的注入点之一。需要检查Service层是否对keyword做了处理。即便做了trim()或简单的替换空格，也防不住注入。
安全方案：必须使用CONCAT函数或bind标签。

<!-- 方案1：使用CONCAT --> <select id="search" resultType="Item"> SELECT * FROM items WHERE title LIKE CONCAT('%', #{keyword}, '%') </select> <!-- 方案2：使用bind标签（MyBatis） --> <select id="search" resultType="Item"> <bind name="pattern" value="'%' + keyword + '%'" /> SELECT * FROM items WHERE title LIKE #{pattern} </select>

实操心得：bind标签创建的pattern变量，在内部也是通过预编译处理的，所以是安全的。这比在Java代码中拼接好%keyword%字符串再传给#{}更清晰。

场景三：IN语句错误做法：SELECT * FROM items WHERE id IN (${ids})。安全做法：使用MyBatis的<foreach>标签遍历集合。

<select id="findByIds" resultType="Item"> SELECT * FROM items WHERE id IN <foreach collection="idList" item="id" open="(" separator="," close=")"> #{id} </foreach> </select>

审计时，如果发现IN语句使用${}拼接，且ids是一个由用户输入的逗号分隔字符串转换而来的列表，风险极高。

3.4 第四步：验证与利用链构造

在代码层面确认存在风险后，如果条件允许（如测试环境），需要构造利用链进行验证。

确定注入类型：是字符型（参数被引号包裹）还是数字型（无引号）？这决定了Payload的构造方式。例如WHERE id = ${id}是数字型，WHERE name = '${name}'是字符型。
测试闭合：对于字符型，首先测试能否闭合引号。传入name=test'，观察应用是否报错（数据库语法错误）。如果报错，说明注入存在。
信息探测：尝试使用UNION SELECT查询数据。需要判断列数，例如：name=test' UNION SELECT 1,2,3 --。如果页面正常显示并出现了数字2或3，说明该位置可以回显数据。
盲注测试：如果无回显，尝试基于布尔或时间的盲注。例如：
- 布尔盲注：name=test' AND SUBSTRING(database(),1,1)='a' --，通过页面内容差异判断真假。
- 时间盲注：name=test' AND IF(1=1, SLEEP(5), 0) --，观察响应是否延迟。
利用工具：可以使用sqlmap进行自动化验证，但前提是已获得测试授权。命令如：sqlmap -u "http://target.com/search?keyword=*" --batch。

注意事项：在真实审计或渗透测试中，必须在授权范围内进行。未经授权的测试是违法行为。

4. 深入MyBatis：`#{}`与`${}`的底层差异与安全边界

很多开发者对MyBatis中#{}和${}的区别停留在“一个安全一个不安全”的层面，但知其然更要知其所以然。理解底层原理，才能更好地审计和编码。

4.1 预编译（PreparedStatement）是如何工作的？

当使用#{}时，MyBatis会创建一个PreparedStatement对象。SQL语句在发送到数据库之前就被编译了，语法结构已经固定。#{}会被替换成一个占位符?。后续传入的参数，无论是什么内容，都只会被当作数据（而不是代码）传递给这个已编译的语句。

// MyBatis（近似）底层做的事 String sql = "SELECT * FROM user WHERE id = ?"; // SQL已编译 PreparedStatement ps = connection.prepareStatement(sql); ps.setInt(1, userId); // 安全地设置参数 ResultSet rs = ps.executeQuery();

数据库知道?的位置应该是一个整数类型的值，因此即使你传入1 OR 1=1，setInt方法也会将其强制转换为整数（可能失败或转换为1），或者直接将其视为一个完整的字符串值，而不会将其解析为SQL语法的一部分。这就从根本上杜绝了注入。

4.2 字符串替换（`${}`）的风险本质

而${}是在SQL语句编译之前就进行简单的字符串替换。你可以把它想象成Java中的字符串拼接。

// 假设 userId = "1 OR 1=1" String sql = "SELECT * FROM user WHERE id = " + userId; // 拼接后：SELECT * FROM user WHERE id = 1 OR 1=1 Statement stmt = connection.createStatement(); // 创建Statement ResultSet rs = stmt.executeQuery(sql); // 执行拼接后的SQL

替换后的完整SQL字符串被送到数据库编译执行。如果其中包含了SQL关键字和语法，数据库就会忠实执行。这就是注入发生的根本原因。

4.3 那些“安全”的`${}`使用场景

审计时，我们也会遇到一些使用了${}但风险极低或可控的情况，不要误报。

硬编码值或常量：
```
ORDER BY ${@com.example.constant.SortConstant@DEFAULT_FIELD}
```
这里的值来自一个静态常量，用户无法控制。
经过严格白名单校验的参数：如前文所述，动态排序字段经过白名单映射后，传入${}的值仅限于id、name等预定义的几个，风险可控。
数字类型且业务逻辑强校验的参数：例如，分页参数${pageNum}，如果业务逻辑确保它只能是大于0的整数（通过Integer.parseInt并判断>0），那么注入空间也很小（但数字型注入理论存在，需结合业务看）。

审计策略：看到${}，不要立刻标记为漏洞。必须完成逆向追踪，确认该参数的源头是否用户可控，以及在到达此处之前是否经过了有效的、不可绕过的安全处理。如果源头不可控或处理有效，则可以放行。

5. 进阶审计技巧与常见盲点

除了常规的CRUD操作，一些复杂的业务场景或框架特性会隐藏更深的注入点。

5.1 MyBatis动态SQL标签中的陷阱

MyBatis的<if>、<choose>、<when>、<otherwise>等动态SQL标签非常强大，但使用不当也会引入风险。

<select id="findUser" parameterType="UserQueryDTO" resultType="User"> SELECT * FROM user WHERE 1=1 <if test="name != null and name != ''"> AND name LIKE '%${name}%' <!-- 危险！在动态标签内使用了${} --> </if> <if test="orderBy != null"> ORDER BY ${orderBy} <!-- 危险！ --> </if> </select>

审计要点：检查动态SQL标签内部使用的表达式。test表达式中的name、orderBy是OGNL表达式，引用的是传入的参数对象属性。如果其中直接使用了${}拼接，风险同样存在。需要追踪UserQueryDTO中name和orderBy属性的来源。

5.2 注解式SQL的审计

MyBatis也支持在Mapper接口方法上直接使用@Select、@Update等注解编写SQL。审计方式与XML类似。

@Select("SELECT * FROM user WHERE username = '${username}'") // 危险！ User findByUsername(@Param("username") String username); @Select("SELECT * FROM user WHERE username = #{username}") // 安全 User findByUsernameSafe(@Param("username") String username);

全局搜索@Select(、@Update(等注解，检查其中的SQL字符串是否包含拼接。

5.3 批量操作与复杂嵌套查询

在批量插入、更新，或者多层子查询中，开发者可能为了性能或灵活性而使用拼接。

<insert id="batchInsert"> INSERT INTO user (name, age) VALUES <foreach collection="userList" item="user" separator=","> ('${user.name}', ${user.age}) <!-- 危险！user.name是字符串 --> </foreach> </insert>

这里虽然用了<foreach>，但内部值仍用${}拼接，应改为#{user.name}和#{user.age}。

5.4 框架自动生成代码的坑

如MyBatis Generator或类似工具生成的代码，通常默认使用#{}。但后续开发者在手动修改功能时，可能会无意中将#{}改为${}，如上文参考案例中的LIKE查询。审计时，对于自动生成的Mapper文件，要重点关注那些与默认生成模式不同的地方，尤其是手写修改过的部分。

6. 修复方案与安全编码规范

审计的最终目的不仅是发现问题，更是推动修复。针对发现的SQL注入点，应提供明确、可操作的修复建议。

6.1 优先使用预编译（`#{}`）

这是铁律。99%的场景都应该使用#{}。

6.2 必须使用`${}`时的安全措施

对于表名、字段名、排序等场景，必须采用白名单机制。

示例：安全的动态ORDER BY实现

@Service public class UserService { private static final Set<String> ALLOWED_SORT_FIELDS = Set.of("id", "create_time", "username"); private static final Set<String> ALLOWED_ORDERS = Set.of("ASC", "DESC"); public List<User> findUsers(String sortField, String sortOrder) { // 1. 白名单校验 if (!ALLOWED_SORT_FIELDS.contains(sortField)) { sortField = "id"; // 默认值 } if (!ALLOWED_ORDERS.contains(sortOrder.toUpperCase())) { sortOrder = "ASC"; } // 2. 可选的额外过滤：移除非字母数字下划线字符（防御性编程） // sortField = sortField.replaceAll("[^a-zA-Z0-9_]", ""); // 3. 将校验后的安全参数传入Mapper return userMapper.findUsersWithOrder(sortField, sortOrder); } }

<!-- Mapper中可以使用${}，因为参数已受控 --> <select id="findUsersWithOrder" resultType="User"> SELECT * FROM user ORDER BY ${safeSortField} ${safeSortOrder} </select>

6.3 LIKE模糊查询的正确姿势

绝对不要使用LIKE '%${value}%'。正确做法：

<!-- MySQL --> <select id="search" resultType="Item"> SELECT * FROM items WHERE title LIKE CONCAT('%', #{keyword}, '%') </select> <!-- 或使用bind标签（数据库无关） --> <select id="search" resultType="Item"> <bind name="pattern" value="'%' + keyword + '%'" /> SELECT * FROM items WHERE title LIKE #{pattern} </select>

6.4 IN语句的正确写法

使用MyBatis的<foreach>标签。

<select id="findByIds" resultType="Item"> SELECT * FROM items WHERE id IN <foreach collection="idList" item="id" open="(" separator="," close=")"> #{id} </foreach> </select>

确保传入的idList是一个List<Integer>或List<Long>，而不是逗号分隔的字符串。在Service层就做好转换和校验。

6.5 全局防御的局限性

有些项目会引入过滤器或拦截器，对请求参数中的SQL关键字进行过滤或转义。但这只能作为辅助手段，绝不能替代参数化查询。

黑名单过滤：容易绕过。如SLEEP(5)可以写成SLEEP/**/(5)、SLEEP(5)（用%00空字节）、或使用编码。
StringEscapeUtils.escapeSql：这是Apache Commons Lang的一个方法，但它仅转义少数字符（如单引号变两个单引号），对于数字型注入或没有引号的注入无能为力，且并非所有数据库都适用。结论：参数化查询（预编译）是唯一公认的、根本的解决方案。其他方法都应在充分评估风险后，作为补充措施。

7. 自动化审计工具辅助与人工审计的平衡

完全依赖工具或完全人工审计都是低效的。应该结合使用。

静态代码分析工具（SAST）：
- SonarQube：可以配置规则检测Java代码中的SQL拼接（如发现Statement.executeQuery拼接字符串）、MyBatis Mapper中的${}使用。
- FindBugs/SpotBugs：有规则能检测JDBC相关的注入问题。
- 专有工具：如Fortify SCA、Checkmarx等商业工具，对Java SQL注入的检测规则比较成熟。
- 局限性：工具会产生大量误报（如把安全的${}常量也报出来）和漏报（尤其是经过多层封装的、逻辑复杂的注入点）。它只能作为初步筛查，所有报告必须经过人工复核。
人工审计的核心价值：
- 理解业务上下文：工具不知道${sortField}是否经过了白名单校验，但人工追踪代码可以。
- 分析复杂数据流：参数可能经过AOP处理、多个Service方法转换、从Session或缓存中获取，工具很难完整追踪。
- 识别逻辑漏洞：工具主要找语法模式，而人工能发现“数字型参数在特定业务逻辑下可能被利用”这类更深层的问题。

推荐的审计流程：

使用SAST工具对全量代码进行扫描，生成初步报告。
根据报告，优先审查高危漏洞点（如Mapper中的${}、Java中的字符串拼接SQL）。
针对核心业务模块（如用户管理、订单查询、搜索功能）进行人工“代码走查”，尤其关注接收外部参数的入口方法。
对发现的问题点，严格遵循“逆向追踪数据流”的方法进行确认。
编写审计报告，清晰描述漏洞位置、风险数据流、利用方式、修复建议。

8. 实战案例复盘：一个电商项目的SQL注入挖掘

去年我审计过一个开源的Spring Boot电商项目，就遇到了一个非常典型的、多层封装的SQL注入案例，它完美展示了审计的完整链条。

漏洞发现：

全局扫描：使用grep -r "\${" --include="*.xml" .，在商品搜索的Mapper文件GoodsMapper.xml中发现：

<select id="searchGoods" resultType="Goods"> SELECT * FROM goods WHERE 1=1 <if test="keyword != null and keyword != ''"> AND (goods_name LIKE '%${keyword}%' OR goods_desc LIKE '%${keyword}%') </if> <if test="orderBy != null"> ORDER BY ${orderBy} </if> </select>

两个高危点：LIKE '%${keyword}%'和ORDER BY ${orderBy}。

逆向追踪：
- 找到GoodsMapper接口中的searchGoods方法，参数是一个Map<String, Object>。
- 在GoodsServiceImpl中找到调用，发现keyword和orderBy都是从传入的SearchDTO对象中获取。
- 追踪到GoodsController，发现一个/goods/search的接口，使用@RequestBody SearchDTO dto接收JSON参数。SearchDTO中有keyword和orderBy字段。
- 关键发现：在Controller和Service层，没有对这两个字段进行任何过滤或校验！
风险确认：
- keyword是字符串，直接用于LIKE拼接，存在明显的字符型注入。
- orderBy也是字符串，用于ORDER BY拼接，存在注入可能。
构造利用：
- 启动本地测试环境。
- 发送POST请求到/goods/search，Body为：{"keyword": "test' AND '1'='1", "orderBy": "id"}
- 观察日志，发现执行的SQL为：... WHERE 1=1 AND (goods_name LIKE '%test' AND '1'='1%' ...，由于单引号被闭合，AND '1'='1成为永真条件，成功注入。
- 进一步，可以构造keyword为test' UNION SELECT 1,2,database(),4,5 --来获取数据库名。
修复建议：
- 将LIKE语句改为LIKE CONCAT('%', #{keyword}, '%')。
- 对orderBy建立白名单：List<String> allowedFields = Arrays.asList("id", "price", "create_time");，校验传入值是否在白名单内，不在则使用默认值。

这个案例的教训是：即使项目使用了MyBatis这样的半自动化框架，如果开发者不了解${}和#{}的安全差异，且缺乏必要的输入校验，依然会制造出严重的漏洞。代码审计的价值，就在于发现这些隐藏在“便捷”功能背后的安全债务。

9. 总结与个人体会

干了这么多年开发和审计，我最大的体会是：安全是一种习惯，而不是一项功能。SQL注入这种“古老”的漏洞之所以经久不衰，不是因为技术有多难防，而是因为开发者在追求功能、赶进度时，最容易牺牲的就是那些“不起眼”的安全细节。

对于开发者，我的建议是：把“使用#{}”刻在肌肉记忆里。每当你要写SQL，手碰到键盘，第一个反应就应该是“这里能不能用#{}？”。如果不能用，立刻警铃大作，然后去查文档、问同事，寻找安全的替代方案（如白名单、CONCAT函数、<foreach>标签）。不要心存侥幸，攻击者不会因为你的业务逻辑简单就放过你。

对于审计者或安全工程师，我们的角色更像是“代码医生”和“布道者”。审计时，要像侦探一样耐心、细致，不放过任何一条数据流。报告问题时，不能只说“这里有SQL注入，高危”，更要清晰地描述攻击路径、提供可立即执行的修复代码，甚至最好能给团队做一次简短的培训，解释为什么${}危险，以及安全的做法是什么。推动修复的过程，也是提升整个团队安全水位的过程。

最后，工具永远在迭代，攻击手段也在翻新，但安全的核心原则——不信任任何用户输入，对输入进行校验、过滤，对输出进行编码，在操作数据时使用参数化查询——是永恒不变的。把这些原则内化到日常开发中，我们才能从源头上减少漏洞的产生，写出更健壮、更可靠的代码。

编程学习技术分享实战经验

资讯详情

Java代码审计实战：SQL注入漏洞挖掘与MyBatis安全编码规范

1. 项目概述：从开发者到审计者的视角转变

2. SQL注入原理与Java中的典型脆弱点

2.1 不同持久层框架下的注入模式

2.2 那些容易被忽略的“合法”拼接场景

3. 代码审计实战：四步定位SQL注入漏洞

3.1 第一步：全局扫描，锁定可疑点

3.2 第二步：逆向追踪，绘制数据流图

3.3 第三步：上下文分析，评估真实风险

3.4 第四步：验证与利用链构造

4. 深入MyBatis：`#{}`与`${}`的底层差异与安全边界

4.1 预编译（PreparedStatement）是如何工作的？

4.2 字符串替换（`${}`）的风险本质

4.3 那些“安全”的`${}`使用场景

5. 进阶审计技巧与常见盲点

5.1 MyBatis动态SQL标签中的陷阱

5.2 注解式SQL的审计

5.3 批量操作与复杂嵌套查询

5.4 框架自动生成代码的坑

6. 修复方案与安全编码规范

6.1 优先使用预编译（`#{}`）

6.2 必须使用`${}`时的安全措施

6.3 LIKE模糊查询的正确姿势

6.4 IN语句的正确写法

6.5 全局防御的局限性

7. 自动化审计工具辅助与人工审计的平衡

8. 实战案例复盘：一个电商项目的SQL注入挖掘

9. 总结与个人体会

最新新闻

日新闻

周新闻

月新闻

资讯详情

Java代码审计实战：SQL注入漏洞挖掘与MyBatis安全编码规范

1. 项目概述：从开发者到审计者的视角转变

2. SQL注入原理与Java中的典型脆弱点

2.1 不同持久层框架下的注入模式

2.2 那些容易被忽略的“合法”拼接场景

3. 代码审计实战：四步定位SQL注入漏洞

3.1 第一步：全局扫描，锁定可疑点

3.2 第二步：逆向追踪，绘制数据流图

3.3 第三步：上下文分析，评估真实风险

3.4 第四步：验证与利用链构造

4. 深入MyBatis：#{}与${}的底层差异与安全边界

4.1 预编译（PreparedStatement）是如何工作的？

4.2 字符串替换（${}）的风险本质

4.3 那些“安全”的${}使用场景

5. 进阶审计技巧与常见盲点

5.1 MyBatis动态SQL标签中的陷阱

5.2 注解式SQL的审计

5.3 批量操作与复杂嵌套查询

5.4 框架自动生成代码的坑

6. 修复方案与安全编码规范

6.1 优先使用预编译（#{}）

6.2 必须使用${}时的安全措施

6.3 LIKE模糊查询的正确姿势

6.4 IN语句的正确写法

6.5 全局防御的局限性

7. 自动化审计工具辅助与人工审计的平衡

8. 实战案例复盘：一个电商项目的SQL注入挖掘

9. 总结与个人体会

相关新闻

最新新闻

日新闻

周新闻

月新闻

4. 深入MyBatis：`#{}`与`${}`的底层差异与安全边界

4.2 字符串替换（`${}`）的风险本质

4.3 那些“安全”的`${}`使用场景

6.1 优先使用预编译（`#{}`）

6.2 必须使用`${}`时的安全措施