RuoYi-3.0代码审计

1 第三方组件漏洞审计

本项目使用Maven构建的。因此我们直接看pom.xml文件引入了哪些组件。通过IDEA打 开该若依，发现本项目采用了多模块方式。因此每个模块下都会有一个pom.xml，项目 最外层的pom.xml为父POM。我们可以通过 pom.xml 或者 External Libraries 来 确定引入组件的版本，具体整理如下：

组件名称	组件版本	是否存在漏洞
shiro	1.4.0	存在
thymeleaf	2.0.0	存在
druid	1.1.10	不存在
mybatis	1.3.2	不存在
bitwalker	1.19	不存在
kaptcha	2.3.2	不存在
swagger	2.7.0	不存在
framework	2.0.5	不存在
fastjson	1.2.36	存在

通过版本号进行初步判断后，我们还需再进一步验证

1.1 shiro反序列化漏洞

1.1.1 shiro密钥硬密码

通过查看pom.xml文件，我们了解到本套项目使用了Shiro组件。我们进一步查看Shiro配置文件时，发现了Shiro密钥硬编码写在了代码文件中。代码位于

D:\code\RuoYi-3.0\ruoyi-framework\src\main\java\com\ruoyi\framework\config\ShiroConfig.java

可以直接通过搜索关键字setCipherKey或CookieRememberMeManager，来看看密钥是否硬编码在了代码中，第331行。如下图所示：

1.1.2 Shiro反序列化漏洞

Apache Shiro框架提供了记住我的功能（RememberMe），用户登陆成功后会生成经过加密并编码的cookie。cookie的key为RememberMe，cookie的值是经过对相关信息进行序列化，然后使用aes加密，最后在使用base64编码处理形成的。在调用反序列化时未进行任何过滤，导致可以触发远程代码执行漏洞。 由于AES加解密的秘钥被硬编码在代码中，这意味着有权访问源代码的任何人都知道默认加密密钥是什么，因此，攻击者可以创建一个恶意对象并对其进行序列化，编码，然后将其作为cookie发送，然后Shiro将解码并反序列化，从而导致恶意代码执行。 通过查看pom.xml文件我们确定了Shiro版本为1.4.0。Shiro 1.4.2版本对于Shiro反序列化来说是个分水岭。由于CVE-2019-12422漏洞的出现，也就是Shiro Padding Oracle Attack漏洞。Shiro在1.4.2版本开始，由AES-CBC加密模式改为了AES-GCM。所以我们在做漏洞验证时，要将payload改成AES-GCM加密模式。

1.1.3 漏洞验证

既然已经得到了密钥为“fCq+/xW488hMTCD+cmJ3aQ==”，那这里就直接用工具打一波试试啦，试不出来再审代码。

1.2 swagger-ui.html接口文档

1.2.1 查看系统文档

1.2.2 点击List Operations 然后构造参数之后，再点击execute执行，拼接路径。

1.2.3 造成信息泄露，获取账号密码。

1.4 计的话就全局搜索：swagger-ui.html，存在的话看下路径然后访问下，看看有没有鉴权什么的。

2 任意文件下载

2.1 文件上传下载漏洞搜索关键词: download、upload、write、fileName、filePath

CommonController.java

2.2构建poc

common/download?filename=/../../../1.txt

3 sql注入

3.1 1 确定使用的持久层框架是mybaits还是Hibeinate或jdbc或自己封装的数据库框架

3.2 确定了使用的框架是mybatis，按照sql注入对应框架的手段全局关键字$检索

其中id为selectRoleList

3.3 继续向上回溯

-->SysRoleServiceImpl.java

3.4 寻找controller

3.5 /system/role/list 接口

3.6 构造数据包，回到文件SysRoleMappper.xml，最初发现的异常点是datascope参数，系统取params.dataScope 参数。

3.7 最后进行复现，执行延时注入

roleName=&roleKey=&status=&params[beginTime]=2022-07-05&params[dataScope]=and 1=2
union select 1,2,3,4,5,6,7,concat(0x7e,(select database()),0x7e),9&pageSize=10&pageNum=1&orderByColumn=roleSort&isAsc=asc

其他接口找寻方法与之类似。

/system/role/export

/system/user/list

/system/user/export

4 xss漏洞

4.1 全局搜索XSS关键字

查看是否设置了防XSS的过滤器且是否生效，如未设置相关的XSS全局过滤器或未开启过滤器或开启过滤器但排除了相关的API，或手动处理【基本遇不到】

总结：三个问题：（1）能否对所有场景的参数全部拦截过滤，比如springmvc注解、struts2接收参数以及fastjson，jackson以及两个框架封装的对象内的全部属性等 （2）系统生产环境是否真正的开启了过滤器，好多研发过滤器通过标识来配置。（3）过滤器是不是对所有的API进行作用，是不是存在不过过滤器的API。

特殊的情况：全局过滤器无法过滤上传文件中的内容，通过在后端读取文件内容后进行手动的编码处理。

4.2 随后便可以对漏洞进行复现

找到system/notice模块下的API入口进行黑盒验证