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.漏洞修复
若依更新日志
修复漏洞代码
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
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
