1.序言

这篇文章是对若依系统v4.6.2版本SQL注入的学习,主要的篇幅集中在若依对该漏洞的修复手段的分析。之前有过对若依系统SQL注入漏洞的分析，可参考文章

审计若依系统v4.6.0 代码审计实战之若依 RuoYi4.6.0

审计若依系统v4.6.1 代码审计ruoyi_v4.6.1之SQL注入详解

2.利用

我们可以使若依综合利用工具一键利用，可以看到漏洞已经修复

若依综合利用工具 https://github.com/20142995/ruoyiVuln

3.漏洞修复

若依更新日志

修复漏洞代码

修复两处存在SQL注入漏洞问题 · e1cab58 · 若依/RuoYi - Gitee.com（https://gitee.com/y_project/RuoYi/commit/e1cab589f2acf4e835ad5ab310bdbe71f2dd646d）

4.断点分析

注入参数params.dataScope

全局搜索，发现params.dataScope参数还是使用了$

burpsuite抓包，构造payload，发送

控制台

payload没有插入sql执行语句，说明已被过滤，接下来我们进行断点分析

首先在SysDeptController.java文件的52行设置断点，参数已经将payload带入list表中

继续跟进（部分传值过程跳过），对比漏洞修复代码，到达该文件的参数params.dataScope的值仍为sql注入语句

经过clearDataScope函数后，params.dataScope参数的值已被清空

接下来，对DataScopeAspect.java文件中的clearDataScope方法进行分析，该段代码表示若params不为空且params继承于BaseEntity，则清空params中的params[dataScope]。

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, "");
}
}

params的对象即为SysDept类的实例，而SysDept类继承于BaseEntity

经过排查，xml中包含$params[dataScope]的SQL方法对应的实体类，每一个类都继承于BaseEntity。

因此若想产生SQL注入，params instanceof BaseEntity必然为true且params必不为空，从而导致dataScope被清空，从而使SQL注入无法生效

但是之前注入的分析中，params.dataScope参数是直接进入handleDataScope函数进行处理的

而在若依系统v4.6.2版本中，params.dataScope参数直接执行了clearDataScope方法，基本可以确定doBefore()方法包含对SQL注入的防护。

注入参数ancestors

在若依系统v4.6.2版本没有找到使用$的参数ancestors，这里不再分析。

5.总结

若依框架对此次SQL注入的防护手段，就是在SQL方法生效之前，先把dataScope清空，即使xml中的SQL语句不变，SQL注入也无法生效了。

参考文章：

https://www.freebuf.com/articles/web/304666.html