CVE-2023-49371漏洞剖析：MyBatis中${}占位符滥用引发的SQL注入风险与修复实践

1. 项目概述：一次典型的企业级框架漏洞深度剖析

最近在梳理一些开源项目的安全历史时，CVE-2023-49371这个编号引起了我的注意。这是一个影响RuoYi若依系统的SQL注入漏洞。RuoYi在国内的中后台管理系统开发圈子里，算得上是“国民级”框架了，很多中小型企业的内部OA、CRM、ERP系统都基于它搭建。正因如此，它的任何一个安全漏洞都可能牵涉甚广。这个CVE编号的漏洞，其本质并不复杂，但非常典型，它暴露了在快速开发框架中，开发者对用户输入过滤和ORM（对象关系映射）使用不当可能带来的连锁风险。今天，我就带大家把这个漏洞掰开揉碎了看，从漏洞成因、环境复现、到修复方案，完整走一遍。无论你是RuoYi的使用者、Java开发者，还是对Web安全感兴趣的朋友，都能从中看到一些在常规开发文档里不会明说的“坑”。

简单来说，CVE-2023-49371允许攻击者通过构造特定的请求参数，在RuoYi系统的某些接口中执行非预期的SQL语句，从而可能导致数据库信息泄露、数据篡改甚至服务器被控制。这个漏洞的评级是“高危”。我们分析它，不是为了攻击，恰恰相反，是为了更深刻地理解“安全编程”的理念，知道漏洞是怎么产生的，才能更好地堵上它。我会用最直白的语言，结合代码片段和实操演示，让你不仅知道“要修复”，更明白“为什么要这样修复”。

2. 漏洞成因深度解析：MyBatis与用户输入的“危险舞蹈”

要理解CVE-2023-49371，我们必须先深入到RuoYi的技术栈里去看。RuoYi后台主要采用Spring Boot + MyBatis Plus这套经典组合。MyBatis是一个优秀的持久层框架，但它把编写SQL的部分权力交给了开发者，这既是灵活性的来源，也可能成为安全问题的根源。这个漏洞的核心，就出在MyBatis的${}占位符滥用和前端参数未经充分校验直接拼接这两个环节上。

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

这是所有MyBatis使用者必须刻在脑子里的第一课，但很多新手甚至老手在赶进度时都会忽略。

• #{}（预编译占位符）：这是安全的。MyBatis会将其转换为一个?占位符，然后通过PreparedStatement来设置参数。数据库驱动会对传入的参数进行严格的类型检查和转义，从根本上杜绝了SQL注入。例如：SELECT * FROM user WHERE id = #{userId}，无论userId传入的是1还是1' OR '1'='1，最终数据库执行的永远是SELECT * FROM user WHERE id = ?，后者传入的恶意字符串只会被当作一个普通的字符串值来处理。
• ${}（字符串替换）：这是危险的。MyBatis会直接进行字符串拼接，将参数的值原封不动地“贴”到SQL语句中。例如：SELECT * FROM user WHERE order_by = ${orderField} LIMIT 10。如果orderField来自用户输入且可控，攻击者传入id; DROP TABLE user --，拼接后的SQL就变成了SELECT * FROM user WHERE order_by = id; DROP TABLE user -- LIMIT 10，一条删除语句就被执行了。

注意：${}并非完全不能用，但它绝对不能用于接收来自用户的可变输入。它通常用于动态指定列名、表名（这些本身不是数据值，且通常由后端逻辑控制）或拼接一些固定的SQL片段。

2.2 RuoYi漏洞代码现场还原

根据公开的漏洞详情和分析，问题出现在RuoYi的某个数据列表查询接口中。我们来看一个高度简化的漏洞代码模型（非原版代码，但原理一致）：

// 假设这是一个用于构建查询条件的Service方法 public List<User> selectUserList(User user, String orderByColumn) { // 这里 orderByColumn 参数直接来自前端的请求（如 ?orderByColumn=create_time） String sqlSort = ""; if (StringUtils.isNotEmpty(orderByColumn)) { // 危险操作：直接将前端传入的字符串用于拼接ORDER BY子句 sqlSort = "ORDER BY " + orderByColumn; } // 在XML中，这个sqlSort变量通过${}被拼接进SQL return userMapper.selectUserList(user, sqlSort); }

对应的MyBatis XML映射文件可能是这样的：

<select id="selectUserList" resultMap="UserResult"> SELECT * FROM sys_user <where> <if test="userName != null and userName != ''"> AND user_name like concat('%', #{userName}, '%')</if> <if test="status != null and status != ''"> AND status = #{status}</if> </where> <!-- 漏洞点：${sqlSort} 直接拼接 --> ${sqlSort} </select>

漏洞触发过程：

1. 攻击者访问列表接口，并传入参数：?orderByColumn=create_time; SELECT SLEEP(5)--
2. 后端sqlSort变量被赋值为："ORDER BY create_time; SELECT SLEEP(5)--"
3. 该字符串通过${sqlSort}直接拼接到SQL中，最终执行的语句变为：

   SELECT * FROM sys_user WHERE ... ORDER BY create_time; SELECT SLEEP(5)--

4. 这变成了两条SQL语句，SELECT SLEEP(5)会被执行，导致数据库线程挂起5秒，证实注入存在。

为什么这里会用${}？我推测原始开发者的意图是为了实现动态排序，而ORDER BY子句后面跟的是列名，不能使用#{}（因为#{}会给列名加上引号，如ORDER BY 'create_time'，这在SQL中是错误的）。但是，他们犯了一个关键错误：没有对传入的orderByColumn值进行严格的白名单校验，而是信任了前端传入的任何字符串。

2.3 框架“便利性”带来的思维盲区

RuoYi以及类似的快速开发框架，为了提升开发效率，会提供大量的代码生成器和通用方法。例如，一个通用的“分页排序查询”方法。开发者在使用这些“黑盒”或“灰盒”方法时，如果不去仔细阅读其内部实现，很容易想当然地认为“框架提供的就是安全的”。这种对框架的过度信任，是此类漏洞在业务系统中潜伏的重要原因。框架的初衷是减少重复劳动，但安全的责任最终必须由使用框架的开发者来承担。

3. 漏洞复现与影响验证实操

“纸上得来终觉浅，绝知此事要躬行。” 在安全领域，亲手复现一个漏洞是理解它的最佳方式。下面我将搭建一个简化的漏洞复现环境，并演示如何验证其存在及危害。请注意，所有操作请在你自己完全可控的本地或测试环境进行，严禁对任何未授权系统进行测试。

3.1 本地测试环境搭建

1. 获取存在漏洞的版本：你需要找到一个受CVE-2023-49371影响的RuoYi版本。通常，漏洞公告会指明影响的版本范围，例如RuoYi v4.x 到某个特定版本。你可以从GitHub的历史发布页面或代码仓库的Tag中下载对应版本的源码。
2. 导入与运行：使用IDEA或Eclipse将项目导入，配置好数据库（通常是MySQL）。根据RuoYi的文档，初始化SQL脚本，创建数据库和表结构。然后运行Spring Boot主类启动项目。
3. 确认接口：你需要找到存在漏洞的具体接口。根据漏洞披露信息，它可能位于系统管理、日志查询或某个业务模块的列表查询功能中。查看相关Controller和Service代码，寻找接收orderByColumn、sort、order等参数且直接用于SQL拼接的方法。

3.2 手工注入验证步骤

假设我们已定位到漏洞接口为/system/user/list，支持orderByColumn参数。

步骤一：基础注入点探测首先发送一个正常请求，观察响应：

GET /system/user/list?pageNum=1&pageSize=10&orderByColumn=create_time&isAsc=desc

响应正常，数据按创建时间降序排列。

步骤二：引入SQL语法试探尝试注入一个永真条件或语法错误，看数据库是否会执行或报错。

# 尝试在排序后添加注释，看是否影响执行 GET /system/user/list?orderByColumn=create_time-- &isAsc=desc # 如果正常返回，说明`--`后的内容被注释，`isAsc`参数可能未生效，提示存在拼接 # 尝试时间盲注：利用数据库延时函数 GET /system/user/list?orderByColumn=create_time; SELECT SLEEP(5)--

此时，观察服务器响应时间。如果请求明显挂起约5秒才返回，那么时间盲注成立，漏洞存在。这就是一个非常经典的验证手法。

步骤三：信息获取验证在确认注入点后，可以尝试构造更复杂的Payload获取信息。例如，在MySQL中，你可以尝试：

# 利用UNION查询获取数据库版本（需要猜测列数） GET /system/user/list?orderByColumn=create_time LIMIT 1) UNION SELECT 1,2,version(),4,5--

这需要你事先知道原查询语句返回的列数，并通过不断调整SELECT后的字段数来匹配。这个过程在实战中可能比较繁琐，但原理相通。

实操心得：在复现这类漏洞时，浏览器的开发者工具（Network标签）是你的好朋友。密切关注每个请求的响应时间和响应体。对于时间盲注，响应时间显著延长是最直接的证据。对于报错注入，响应体中的数据库错误信息会直接暴露出来。复现的目的不是为了“攻击成功”，而是为了在可控环境下亲眼看到漏洞被触发的现象，从而加深理解。

3.3 使用Sqlmap进行自动化验证（可选）

对于已经明确注入点和参数的手工验证，也可以使用Sqlmap这类自动化工具进行更全面的检测，它能帮你快速识别数据库类型、当前用户、数据库名等信息。

# 基本检测命令 sqlmap -u "http://your-test-ip:port/system/user/list?orderByColumn=create_time&isAsc=desc" --risk=3 --level=3 # 指定注入参数 sqlmap -u "http://your-test-ip:port/system/user/list" --data="orderByColumn=create_time&isAsc=desc" -p "orderByColumn"

使用自动化工具时务必谨慎，避免对测试数据库造成意外修改或过度负载。再次强调，仅用于授权的测试环境。

4. 漏洞修复方案与最佳实践

找到漏洞只是第一步，更重要的是如何正确地修复它，并且举一反三，避免同类问题。针对CVE-2023-49371，修复的核心思路就一句话：将不安全的${}字符串替换，改为安全的#{}预编译，或者对输入进行严格的过滤校验。

4.1 直接修复方案：白名单校验

这是修复动态排序/列名问题的最常见、最有效方法。既然ORDER BY后面不能直接用#{}，那我们就在拼接之前，确保传入的值是合法的。

修复后代码示例：

// 1. 定义一个允许排序的列名白名单 private static final Set<String> ALLOWED_SORT_COLUMNS = new HashSet<>(Arrays.asList( "create_time", "update_time", "user_id", "user_name", "status" )); public List<User> selectUserList(User user, String orderByColumn, String isAsc) { String sqlSort = ""; if (StringUtils.isNotEmpty(orderByColumn) && StringUtils.isNotEmpty(isAsc)) { // 关键修复：检查传入的列名是否在白名单内 if (ALLOWED_SORT_COLUMNS.contains(orderByColumn.toLowerCase())) { // 同时，对排序方向也做校验，只允许 ASC 或 DESC if ("asc".equalsIgnoreCase(isAsc) || "desc".equalsIgnoreCase(isAsc)) { // 注意：这里列名是经过校验的，但为了绝对安全，可以进一步处理（如映射） // 直接拼接，因为列名是受控的 sqlSort = String.format(" ORDER BY %s %s", orderByColumn, isAsc.toUpperCase()); } } else { // 不在白名单内，可以记录日志、抛出异常或使用默认排序 log.warn("非法的排序字段请求: {}", orderByColumn); sqlSort = " ORDER BY create_time DESC"; // 使用安全的默认值 } } return userMapper.selectUserList(user, sqlSort); }

在XML中，${sqlSort}的用法可以保留，因为此时sqlSort字符串的内容（如ORDER BY create_time DESC）已经完全由后端逻辑控制，不包含任何用户输入的数据值。

为什么这是最佳实践？

1. 确定性：系统只允许对预设的几列进行排序，符合最小权限原则。
2. 简单有效：白名单机制在安全上远优于黑名单（试图过滤所有非法字符），因为你定义的是“什么是被允许的”，而不是“什么是不被允许的”，后者永远可能存在遗漏。
3. 可维护：如果需要新增可排序字段，只需更新ALLOWED_SORT_COLUMNS这个集合即可。

4.2 进阶修复方案：使用MyBatis的拦截器或工具类

对于大型项目，可能有多个地方需要动态排序。我们可以编写一个通用的工具类或利用MyBatis的插件（Interceptor）来统一处理SQL拼接的安全问题。

方案A：SQL工具类

public class SqlSafeUtil { private static final Pattern VALID_COLUMN_NAME = Pattern.compile("^[a-zA-Z_][a-zA-Z0-9_]*$"); /** * 安全地构建ORDER BY子句 * @param orderByColumn 排序列名 * @param isAsc 排序方向 * @param defaultSort 默认排序语句 * @return 安全的ORDER BY字符串，或默认值 */ public static String buildSafeOrderBy(String orderByColumn, String isAsc, String defaultSort) { if (StringUtils.isBlank(orderByColumn) || StringUtils.isBlank(isAsc)) { return defaultSort; } // 1. 正则校验列名格式（防注入第一道关） if (!VALID_COLUMN_NAME.matcher(orderByColumn).matches()) { return defaultSort; } // 2. 白名单校验（第二道关，更严格） // if (!ALLOWED_COLUMNS.contains(orderByColumn)) { ... } // 3. 校验排序方向 String direction = "asc".equalsIgnoreCase(isAsc) ? "ASC" : "DESC"; if (!"ASC".equals(direction) && !"DESC".equals(direction)) { direction = "ASC"; } return String.format(" ORDER BY %s %s", orderByColumn, direction); } }

然后在Service中调用：sqlSort = SqlSafeUtil.buildSafeOrderBy(orderByColumn, isAsc, "create_time DESC");

方案B：MyBatis拦截器（更底层）你可以编写一个拦截器，在MyBatis执行SQL前，对包含${}的SQL片段进行全局的语法分析和安全校验。这种方法更彻底，但对开发者要求较高，且可能影响性能。

4.3 框架层加固建议

对于使用RuoYi或类似框架的团队，除了修复具体漏洞，还应从框架使用规范上建立防线：

1. 代码审计制度化：在项目上线前，或定期对代码进行安全审计，重点审查Mapper XML文件中所有使用${}的地方，追溯其参数来源。
2. 依赖库升级：关注RuoYi官方GitHub仓库的Release和Security Advisories。对于已公开的漏洞，官方通常会发布修复版本。及时将框架升级到安全版本是最省力的方法。
3. 输入验证全局化：不仅在Controller层做参数校验（如使用JSR-303的@Valid），在Service层，尤其是参数即将参与SQL构建、命令执行、文件路径拼接等危险操作前，必须进行二次校验。
4. 避免动态SQL滥用：MyBatis的动态SQL标签（<if>,<choose>,<foreach>）非常强大，但和${}结合时要万分小心。尽量使用<foreach>配合#{}来处理IN查询，而不是拼接字符串。

5. 从漏洞看安全开发意识的养成

CVE-2023-49371虽然修复起来不难，但它像一面镜子，映照出许多开发团队在安全开发流程上的缺失。修复一个已知漏洞是“治标”，建立主动的安全防御意识才是“治本”。

5.1 开发者常见的安全误区

• “前端已经校验了”：这是最危险的念头之一。攻击者完全可以绕过浏览器，直接通过工具（如Postman, Curl）构造请求发送给后端。所有安全检查必须以后端为准。
• “框架是安全的”：框架提供了安全的基础组件（如Spring Security），但无法为你的业务逻辑代码背书。框架的便捷方法也可能存在误用风险，就像这个漏洞中的动态排序。
• “我们系统小，没人会攻击”：自动化攻击脚本不会区分系统大小。你的服务器可能只是攻击者僵尸网络扫描千万个IP中的一个，一旦发现漏洞就会被利用。
• “用了ORM就绝对安全”：MyBatis、JPA等ORM框架确实能避免大部分常见的注入，但只要你写原生SQL或使用不当的API（如JPA的@Query配合字符串拼接），风险依然存在。

5.2 将安全嵌入开发生命周期（SDL）

1. 需求与设计阶段：在评审功能时，就考虑安全需求。例如，“这个排序功能，允许用户按哪些字段排序？”这个问题应该在设计时就明确，并转化为后端白名单。
2. 编码阶段：遵循安全编码规范。团队内部可以制定一个《安全编码Checklist》，其中必须包含：“禁止将用户输入直接用于SQL拼接”、“使用#{}而非${}”、“所有外部输入必须校验”等条款。
3. 测试阶段：引入安全测试。除了功能测试，应进行渗透测试或使用SAST（静态应用安全测试）工具扫描代码。可以搭建类似DVWA、Pikachu这样的漏洞靶场，让开发人员亲自体验攻击过程，从而深刻理解漏洞。
4. 部署与运维阶段：配置WAF（Web应用防火墙）作为最后一道防线。WAF可以拦截常见的SQL注入、XSS等攻击Payload。同时，监控日志，对异常的、包含大量SQL特殊字符的请求进行告警。

5.3 针对SQL注入的持续防御策略

• 最小权限原则：连接数据库的账号，不应该拥有DROP、DELETE、UPDATE等高危权限。根据业务需要，只授予SELECT和必要的INSERT权限。
• 预编译语句全覆盖：确保项目中99%的数据库操作都使用预编译（PreparedStatement）或ORM框架的安全查询方式。对剩下的1%（如动态表名、列名）进行重点审计和安全封装。
• 定期安全培训：技术更新快，攻击手段也在进化。定期组织开发团队学习最新的安全漏洞案例（就像分析CVE-2023-49371一样），保持对安全威胁的敏感度。
• 建立漏洞响应机制：当发现第三方组件（如RuoYi框架）爆出漏洞时，团队应能快速评估影响、制定修复或升级方案、并执行上线，将风险窗口期降到最低。

6. 总结与个人体会

回顾整个CVE-2023-49371漏洞，从成因到修复，其技术原理并不高深，但它能成为一个高危CVE，恰恰说明了“魔鬼在细节中”。很多严重的安全问题，都源于开发中对一些基础规则（如#{}和${}的区别）的忽视或对便利性的过度追求。

我个人在多年的开发和审计经历中，有一个很深的体会：安全更像是一种习惯，而不是一项技术。它体现在你每次接收用户输入时下意识的怀疑，体现在你编写SQL时对手指打出的每一个$符号的警惕，体现在你选择相信白名单而非黑名单的思维定式。修复RuoYi的这个漏洞，可能只需要修改几行代码，但培养起整个团队这种“安全习惯”，却需要长期的坚持和制度保障。

对于正在使用RuoYi的开发者，我建议立即检查你们项目中的所有Mapper XML文件，搜索${，逐一审查其参数是否可控、是否经过校验。这个工作可能有点枯燥，但远比事后被攻击、被拖库要轻松得多。对于其他技术栈的开发者，这个案例同样具有普适的警示意义：任何将用户输入与代码/命令混合执行的地方，都是潜在的风险点，无论是SQL、OS命令、模板渲染还是反序列化。

最后，安全之路没有终点。每一个被发现的CVE，都是我们提升防御能力的一次宝贵学习机会。保持好奇，保持谨慎，代码的世界才能更稳健地运行。