1.序言
根据官网的更新日志，若依系统v4.6.1版本并没有修复存在的SQL注入漏洞问题，所以这篇文章既可以看做若依系统v4.6.1版本SQL注入漏洞的分析，也可以看做若依系统v4.6.0版本SQL注入的补充。
1）审计若依系统v4.6.0
2）官网更新日志：
2.审计
(1)注入点1
SysDeptMapper.xml文件的params.dataScope参数
SpringBoot中的SQL注入一般都是因为使用了 $ 的原因。可以全局搜索 $ 并匹配 .xml 文件类型，快速查看是否存在SQL注入，发现前端多个位置存在这个注入点。
那就选择第一个先跟一下流程，现在是在resources中的SysDeptMapper.xml文件中。
找到 id 然后按住ctrl+左键进入到dao(mapper)层。
继续在 selectDeptList 上按住ctrl+左键往上，跟看谁调用的，会发现有四个选择，第四个肯定不是了，从那来的，另外三个都在一个文件中，随便选择一个。
来到serveice层，根据注释和代码发现，第一处是查询部门数据，就是在部门管理的功能处
继续跟 selectDeptList 进入 controller 层，发现最终前端调用处为调用列表的相关功能，比如搜索，刷新等操作，路径为/system/dept/list，请求方式为post。
验证：
(1)根据路由信息，找到系统对应的功能点,在这里我们可以定位到部门管理的编辑操作
(2)然后抓包，发送到repeater模块，构造poc，发现 POST 请求体里没有params[dataScope]字段，于是尝试将 POST 请求体替换为以下 POC：
deptName=&status=&params[dataScope]=and extractvalue(1,concat(0x7e,substring((select database()),1,32),0x7e))
现在，我们开始研究注入点参数params[dataScop]
我们看到，根据上述注入过程，猜测注入点参数是params.dataScope，但是直接带入params.dataScope参数，利用burpsuite进行注入测试
看到所有报错注入语句均未成功注入，说明params.dataScope不是正确的报错参数。
但是看到IDEA后台运行语句，同时在.xml文件处发现注释，又注意到parent_id，dept_name，status为空，初步判断，框中执行的应该就是params.dataScope参数带入的SQL语句。
我们对其中的sql语句进行全局搜索，
SELECT dept_id FROM sys_role_dept WHERE role_id =
结果在DataScopeAspect.java文件中找到了它，且看到了dataScope参数，dataScope参数是从role.getDataScope()函数中传过来的，而role又是从user.getRoles()函数中获得的，追踪user.getRoles()函数
最终只能追踪到list.java
现在我们需要通过断点来判断传值过程及在此过程中，参数的变化，参数值的变化来判断一个正确的注入参数
从注入点的路由我们找到其控制器，在从list中获取值的地方断点
在1处我们既没有发现dataScope参数，也没有发现params.dataScope参数，但是我们在2处发现了params参数，继续看传值过程（在此过程中，具体传值过程跳过）
我们发现在params参数里包含了dataScope参数，且其中的值被[]包含。我们初步判断，正确的注入参数应该是params[dataScope],利用burpsuite进行测试
该SQL注入语句已成功执行
从程序运行的控制台看到，该SQL注入语句已经注入到原SQL语句
全局搜索，排查还有哪些功能点用到selectDeptList(dept)函数
补充：参数params与参数dataScope的关系 ${params.dataScope}的意思就是入参参数.dataScope属性,即 SysDept对象.dataScope属性
具体可参考以下链接：
https://blog.csdn.net/weixin_40967156/article/details/116265306
https://blog.csdn.net/qq_52469048/article/details/127676460
https://developer.aliyun.com/article/1410226
注入点2
ysDeptMapper.xml文件的参数ancestors
同理，我们在SysDeptMapper.xml文件中找到了第二个可能拥有SQL注入点的参数ancestors
还是进行跟进，找到使用该函数的功能点
最终，我们在controller层SysDeptController.java文件中找到了该函数，
然后根据路由找到功能点
对市场部门进行编辑
在burpsuite中找到数据包
然后直接改包，构造payload
在响应中未发现注入
查看控制台
我们发现sql语句的执行过程：
① 首先进行dept_name和parent_id的查询（select）
② 其次进行dept_id的查询（select）
③ 查询 sys_dept 表中，ancestors 字段包含指定值（?）的所有记录（select）
④ 然后更新parent_id , dept_name , ancestors 等数据（update）
⑤ 最后进行对数据的插入（insert）
在整个过程中我们发现dept_id的值是101，但ancestors的范围是（0,100），显然此部门不在ancestors范围之内。
我们回头看在.xml文件中sql语句的执行
SQL 的 WHERE 子句，表示限制更新的条件。具体来说，它根据 dept_id 字段来筛选符合条件的记录，dept_id 必须在 ${ancestors} 中，简而言之，dept_id必须在100以内才能。才能执行该处的更新语句。
我们选择若依科技，然后点击修改，确定，抓包
我们发现dept_id=100，尝试注入，构造payload，进行测试
出现了报错，说明此处有注入，利用burpsuite的intruder模块FUZZ一波
然后全局搜索还有哪个地方用到了updateDeptStatus方法
注入点3
SysRoleMapper.xml文件的${params.dataScope}参数
同理，持续跟进
全局搜索
进入dao层
进入service层
在controller层，我们看到有两个地方用到了selectRoleList方法
我们首先看第一个
我们根据其路由信息找到功能点
然后直接构造payload,进行测试
pageSize=10&pageNum=1&orderByColumn=roleSort&isAsc=asc&roleName=&roleKey=&status=¶ms%5BbeginTime%5D=¶ms%5BendTime%5D=params[dataScope]=and extractvalue(1,concat(0x7e,substring((select user()),1,32),0x7e))
再看第二个
分析流程类似注入点1，这里不再赘述。
注入点4
SysUserMapper.xml文件的${params.dataScope}
全局搜索（找dao层文件）
进入dao层文件
进入service层
任选一个，进入controller层
根据路由信息找到功能点
进入用户界面操作
Burpsuite抓包
构造payload,进行测试
pageSize=10&pageNum=1&orderByColumn=createTime&isAsc=desc&deptId=&parentId=&loginName=&phonenumber=&status=¶ms%5BbeginTime%5D=¶ms%5BendTime%5D=params[dataScope]=and extractvalue(1,concat(0x7e,substring((select user()),1,32),0x7e))
存在SQL注入漏洞
故凡是调用selectUserList方法的功能点皆存在SQL注入漏洞。
3.总结
此处SQL注入漏洞的分析都是在漏洞复现后的基础上进行的，有疏漏和错误的地方请各位老师指教。
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
