代码审计ruoyi_v4.6.2 | SQL注入详解
字数 1899 2025-08-20 18:17:47

若依系统v4.6.2 SQL注入漏洞分析与修复机制详解

1. 序言与背景

本文详细分析若依(RuoYi)系统v4.6.2版本中SQL注入漏洞的修复机制。若依系统是一个基于Spring Boot的权限管理系统,广泛应用于企业级开发中。在v4.6.2版本中,开发团队修复了两处SQL注入漏洞问题,本文将重点分析其修复手段。

相关历史漏洞分析参考:

  • 审计若依系统v4.6.0
  • 代码审计实战之若依 RuoYi4.6.0
  • 审计若依系统v4.6.1
  • 代码审计ruoyi_v4.6.1之SQL注入详解

2. 漏洞利用验证

若依综合利用工具(https://github.com/20142995/ruoyiVuln)可用于验证该漏洞是否已被修复。测试表明,在v4.6.2版本中,相关SQL注入漏洞已被成功修复。

3. 漏洞修复概述

修复提交记录可见于Gitee:
https://gitee.com/y_project/RuoYi/commit/e1cab589f2acf4e835ad5ab310bdbe71f2dd646d

主要修复了两处存在SQL注入漏洞的问题。

4. 漏洞详细分析

4.1 params.dataScope参数注入分析

漏洞位置分析:

  1. 全局搜索发现params.dataScope参数仍使用了$符号进行拼接(MyBatis中$表示直接拼接SQL,存在注入风险)
  2. 通过BurpSuite构造payload测试,发现payload没有被执行,说明已被过滤

断点分析过程:

  1. SysDeptController.java文件的52行设置断点

    • 参数已将payload带入list表中
    • 继续跟进传值过程,发现params.dataScope参数的值仍为SQL注入语句
  2. 关键修复点 - clearDataScope函数:

    • 经过clearDataScope函数后,params.dataScope参数的值被清空
    • 该函数位于DataScopeAspect.java文件中

修复代码分析:

private void clearDataScope(final JoinPoint joinPoint) {
    Object params = joinPoint.getArgs()[0];
    if (StringUtils.isNotNull(params) && params instanceof BaseEntity) {
        BaseEntity baseEntity = (BaseEntity) params;
        baseEntity.getParams().put(DATA_SCOPE, "");
    }
}

修复机制解析:

  1. params对象是SysDept类的实例,而SysDept继承于BaseEntity
  2. 所有XML中包含$params[dataScope]的SQL方法对应的实体类都继承于BaseEntity
  3. 因此当满足以下条件时,dataScope会被清空:
    • params不为空
    • paramsBaseEntity的实例(params instanceof BaseEntity为true)
  4. 在v4.6.2版本中,params.dataScope参数会先执行clearDataScope方法,然后才进入handleDataScope函数处理

防护机制总结:

  • 通过在SQL方法生效前清空dataScope参数
  • 即使XML中的SQL语句保持不变(仍使用$拼接),SQL注入也无法生效

4.2 ancestors参数注入分析

在若依系统v4.6.2版本中,未找到使用$符号拼接的ancestors参数,因此不再进行分析。

5. 修复方案总结

若依框架对SQL注入的防护手段主要包含以下关键点:

  1. 前置清理机制

    • 在SQL方法执行前,通过AOP切面(DataScopeAspect)清理潜在的注入参数
    • 特别是针对dataScope参数,在进入SQL处理前就被清空
  2. 继承体系利用

    • 利用Java继承特性,通过BaseEntity基类识别需要清理的参数对象
    • 所有相关实体类都继承自BaseEntity,确保清理逻辑全覆盖
  3. 防御深度

    • 不依赖SQL语句本身的修改(仍保留$拼接)
    • 从参数源头进行清理,提供更深层次的防御

6. 安全建议

  1. 对于使用若依系统的开发者:

    • 及时升级到最新版本
    • 检查自定义代码中是否使用了$符号进行SQL拼接
    • 遵循若依的安全处理模式,对用户输入进行严格过滤
  2. 对于安全研究人员:

    • 关注若依系统的更新日志和安全公告
    • 使用若依综合利用工具进行漏洞验证
    • 学习这种前置清理的防御思路,应用于其他系统审计中

7. 参考资源

  1. 若依系统官方仓库:https://gitee.com/y_project/RuoYi
  2. 若依综合利用工具:https://github.com/20142995/ruoyiVuln
  3. 相关漏洞修复提交:https://gitee.com/y_project/RuoYi/commit/e1cab589f2acf4e835ad5ab310bdbe71f2dd646d
若依系统v4.6.2 SQL注入漏洞分析与修复机制详解 1. 序言与背景 本文详细分析若依(RuoYi)系统v4.6.2版本中SQL注入漏洞的修复机制。若依系统是一个基于Spring Boot的权限管理系统,广泛应用于企业级开发中。在v4.6.2版本中,开发团队修复了两处SQL注入漏洞问题,本文将重点分析其修复手段。 相关历史漏洞分析参考: 审计若依系统v4.6.0 代码审计实战之若依 RuoYi4.6.0 审计若依系统v4.6.1 代码审计ruoyi_ v4.6.1之SQL注入详解 2. 漏洞利用验证 若依综合利用工具(https://github.com/20142995/ruoyiVuln)可用于验证该漏洞是否已被修复。测试表明,在v4.6.2版本中,相关SQL注入漏洞已被成功修复。 3. 漏洞修复概述 修复提交记录可见于Gitee: https://gitee.com/y_ project/RuoYi/commit/e1cab589f2acf4e835ad5ab310bdbe71f2dd646d 主要修复了两处存在SQL注入漏洞的问题。 4. 漏洞详细分析 4.1 params.dataScope参数注入分析 漏洞位置分析: 全局搜索发现 params.dataScope 参数仍使用了 $ 符号进行拼接(MyBatis中 $ 表示直接拼接SQL,存在注入风险) 通过BurpSuite构造payload测试,发现payload没有被执行,说明已被过滤 断点分析过程: 在 SysDeptController.java 文件的52行设置断点 参数已将payload带入list表中 继续跟进传值过程,发现 params.dataScope 参数的值仍为SQL注入语句 关键修复点 - clearDataScope 函数: 经过 clearDataScope 函数后, params.dataScope 参数的值被清空 该函数位于 DataScopeAspect.java 文件中 修复代码分析: 修复机制解析: params 对象是 SysDept 类的实例,而 SysDept 继承于 BaseEntity 所有XML中包含 $params[dataScope] 的SQL方法对应的实体类都继承于 BaseEntity 因此当满足以下条件时, dataScope 会被清空: params 不为空 params 是 BaseEntity 的实例( params instanceof BaseEntity 为true) 在v4.6.2版本中, params.dataScope 参数会先执行 clearDataScope 方法,然后才进入 handleDataScope 函数处理 防护机制总结: 通过在SQL方法生效前清空 dataScope 参数 即使XML中的SQL语句保持不变(仍使用 $ 拼接),SQL注入也无法生效 4.2 ancestors参数注入分析 在若依系统v4.6.2版本中,未找到使用 $ 符号拼接的 ancestors 参数,因此不再进行分析。 5. 修复方案总结 若依框架对SQL注入的防护手段主要包含以下关键点: 前置清理机制 : 在SQL方法执行前,通过AOP切面( DataScopeAspect )清理潜在的注入参数 特别是针对 dataScope 参数,在进入SQL处理前就被清空 继承体系利用 : 利用Java继承特性,通过 BaseEntity 基类识别需要清理的参数对象 所有相关实体类都继承自 BaseEntity ,确保清理逻辑全覆盖 防御深度 : 不依赖SQL语句本身的修改(仍保留 $ 拼接) 从参数源头进行清理,提供更深层次的防御 6. 安全建议 对于使用若依系统的开发者: 及时升级到最新版本 检查自定义代码中是否使用了 $ 符号进行SQL拼接 遵循若依的安全处理模式,对用户输入进行严格过滤 对于安全研究人员: 关注若依系统的更新日志和安全公告 使用若依综合利用工具进行漏洞验证 学习这种前置清理的防御思路,应用于其他系统审计中 7. 参考资源 若依系统官方仓库:https://gitee.com/y_ project/RuoYi 若依综合利用工具:https://github.com/20142995/ruoyiVuln 相关漏洞修复提交:https://gitee.com/y_ project/RuoYi/commit/e1cab589f2acf4e835ad5ab310bdbe71f2dd646d