一、项目部署

1、Java环境

使用java1.8.0_301版本进行部署

2、Maven

使用IDEA内置的Maven

3、Mysql环境部署

使用老版本的phpstudy搭建

创建数据库并导入数据

4、项目搭建

导入项目到IDEA

修改数据库连接信息

5、项目启动

项目启动之后访问127.0.0.1:8088即可访问到如下的登录页面

二、组件漏洞审计

本项目是基于Maven构建的。对于Maven项目，我们首先要从pom.xml文件开始审计引入的第三方组件的版本是否为漏洞版本，再进一步验证组件是否存在漏洞

组件名称	组件版本
Sping boot	2.3.1
Spring security	5.3.3
actuator	2.31
fastjson	1.2.56
thymeleaf	3.0.11
mybatis	2.1.2
swagger2	2.9.2
druid	1.1.21
easy-captcha	1.6.2
oshi-core	4.4.2
pagehelper	1.2.13
hutool	5.1.4

1、Spring boot

Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化Spring应用的创建、运行、调试、部署等。使用Spring Boot可以做到专注于Spring应用的开发，而无需过多关注XML的配置。

在网上检索了Spring boot框架的漏洞，只找到一个很老的，如下

Spring Boot框架SPEL表达式注入漏洞（**< v1.3.0**）

本项目的Spring Boot版本为2.3.1,所以不存在该漏洞，暂时放弃

2、Spring security

Spring Security 是Spring家族中的一个安全管理框架。核心功能就就是认证与授权。

该项目的Spring security版本为5.3.3，在网上把Spring security的历史的认证绕过CVE检索了一下，发现该版本只受到一个漏洞影响

CVE-2022-22978 RegexRequestMatcher认证绕过漏洞

但是该漏洞需要使用到RegexRequestMatcher方法进行正则匹配，本次项目并没有用到，所以暂时放弃该组件漏洞的查找

3、Actuator

Spring Boot Actuator 是 Spring Boot 提供的用于监控和管理应用程序的模块。它提供了一组现成的端点，可以让我们方便地监控和管理应用程序。这些端点包括健康状况、性能指标、配置信息、日志等。通过这些端点，我们可以了解应用程序的运行状况，及时发现和解决问题，提高应用程序的可用性和可维护性。

actuator的漏洞主要是未授权访问漏洞

组件端点位置如下

Spring Boot 1.x版本端点在根URL下注册
Spring Boot 2.x版本端点移动到/actuator/路径

组件未授权情况如下

Spring Boot < 1.5 默认未授权访问所有端点
Spring Boot >= 1.5 默认只允许访问/health和/info端点，但是此安全性通常被应用程序开发人员禁用。

因为这里的版本是2.31，所以端点是/actuator/路径，并且默认是不能访问其他敏感端口的，Actuator提供了13个接口，如下

GET	/auditevents	显示应用暴露的审计事件 (比如认证进入、订单失败)
GET	/beans	描述应用程序上下文里全部的 Bean，以及它们的关系
GET	/conditions	就是 1.0 的 /autoconfig ，提供一份自动配置生效的条件情况，记录哪些自动配置条件通过了，哪些没通过
GET	/configprops	描述配置属性(包含默认值)如何注入Bean
GET	/env	获取全部环境属性
GET	/env/{name}	根据名称获取特定的环境属性值
GET	/flyway	提供一份 Flyway 数据库迁移信息
GET	/liquidbase	显示Liquibase 数据库迁移的纤细信息
GET	/health	报告应用程序的健康指标，这些值由 HealthIndicator 的实现类提供
GET	/heapdump	dump 一份应用的 JVM 堆信息
GET	/httptrace	显示HTTP足迹，最近100个HTTP request/repsponse
GET	/info	获取应用程序的定制信息，这些信息由info打头的属性提供
GET	/logfile	返回log file中的内容(如果 logging.file 或者 logging.path 被设置)
GET	/loggers	显示和修改配置的loggers
GET	/metrics	报告各种应用程序度量信息，比如内存用量和HTTP请求计数
GET	/metrics/{name}	报告指定名称的应用程序度量值
GET	/scheduledtasks	展示应用中的定时任务信息
GET	/sessions	如果我们使用了 Spring Session 展示应用中的 HTTP sessions 信息
POST	/shutdown	关闭应用程序，要求endpoints.shutdown.enabled设置为true
GET	/mappings	描述全部的 URI路径，以及它们和控制器(包含Actuator端点)的映射关系
GET	/threaddump	获取线程活动的快照

此时我们就要去看看开发人员开启了哪些配置，如果没有配置的话就是默认的/info和/health端点了，也就没有什么危害

这里我们可以通过配置文件，即application.yml文件查看配置状态，直接全局搜索endpoints也可以查看，如下

可以看到确实在application.yml文件中

经过观察发现开发人员修改了这个配置，主动开启了如下几个端点

/beans
/env
/metrics

其中那么就可以初步判断这个位置存在未授权访问漏洞，等待之后验证

拓展一下：

这里include如果是下面这样的话，就是开启所有端口

 include "*"

这里说的2.0的路由是/actuator/，我在网上找了一下，其实这个也可以自定义，如下配置即可

management:
endpoints:
 web:
   base-path: /manage

此时的路由就会变为/manage，就可以防止一些黑盒层面的目录遍历查找出未授权访问。

4、Fastjson

FastJson是阿里巴巴的的开源库，用于对JSON格式的数据进行解析和打包。能够支持将java bean序列化成JSON字符串，也能够将JSON字符串反序列化成Java bean

这里的fastjson版本是 1.2.56，经过搜索，发现该版本存在反序列化漏洞，这里就要讲一下fastjson常见的两种处理JSON的方法

JSON.toJSONString()方法：可将对象转换成JSON字符串
JSON.parseObject()方法：将JSON字符串转换成对象。

Fastjson该版本的漏洞也正是这两个函数的使用导致的问题，所以全局搜索这两个函数，如下

但是并没有搜到，那这里说明什么呢？说明该项目虽然导入了Fastjson，但是没有使用，自然也就不存在对应的漏洞，所以放弃这个点

5、thymeleaf

thymeleaf这里的版本是3.0.11

模板注入

Thymeleaf 3.0.0 至 3.0.11 版本存在模板注入漏洞，具体的漏洞判断与利用可以看下面的文章

https://blog.csdn.net/m0_71692682/article/details/130538310

但经过测试，这里并不存在模板注入，基本都使用了@ResponseBody注解

@ResponseBody 是一个Spring框架中的注解，它用于指示该方法的返回值应该直接写入HTTP响应正文ResponseBody中，而不是通过视图解析器进行渲染 。使用 @ResponseBody 注解可以将方法返回值以JSON、XML等格式直接写入HTTP响应体中，常用于返回 RESTful API 接口的响应数据。

XSS

Thymeleaf中 th:text 标签进行渲染的时候，默认对特殊字符进行了转义，而th:utext 不会将字符转

义。也就是说使用了 th:utext 标签会出现XSS漏洞。

经过全局搜索，发现有两处使用了 th:text 标签。没有地方使用 th:utext 标签。所以基于Thymeleaf的XSS审计也暂时放弃

6、Mybatis

mybatis是一款用于持久层的、轻量级的半自动化ORM框架，封装了所有jdbc操作以及设置查询参数和获取结果集的操作，支持自定义sql、存储过程和高级映射。

这里的mybatis的版本是2.1.2。经过查找，发现该版本存在一个远程代码执行漏洞CVE-2020-26945

但是有三个条件

用户启用了内置的二级缓存
用户未设置JEP-290过滤器
攻击者找到了一种修改私有Map字段条目的方法，即修改org.apache.ibatis.cache.impl.PerpetualCache.cache有效的缓存密钥

利用条件不满足，放弃该漏洞的审计

7、swagger2

Swagger 是一个开源的 API 设计和文档工具，它可以帮助开发人员更快、更简单地设计、构建、文档化和测试 RESTful API。Swagger 可以自动生成交互式 API 文档、客户端 SDK、服务器 stub 代码等，从而使开发人员更加容易地开发、测试和部署 API。

swagger的漏洞主要还是一个未授权访问漏洞

因为这个项目用的是SpringSecurity，所以我们可以去Springsecurity的配置文件——SpringSecurityConfig中看看是否对swagger做了权限校验

可以看到它这里直接放行了swagger的页面，所以判断这里也是存在未授权访问漏洞的

8、Druid漏洞审计

Druid是阿里巴巴数据库出品的，为监控而生的数据库连接池，并且Druid提供的监控功能，监控SQL的执行时间、监控Web URI的请求、Session监控，首先Druid是不存在什么漏洞的。但当开发者配置不当时就可能造成未授权访问。

它存在的漏洞网上大致可以找到未授权访问和密码可爆破两个点

未授权访问

这里的druid版本为1.1.21，经过网上的搜索，发现只有一个未授权漏洞，并且这个未授权漏洞是因为程序员的错误配置导致的，而不是druid本身的漏洞

Alibaba Druid 默认情况下未设置访问控制，攻击者可以登录以获取敏感信息。这里有两种情况可以防止这个未授权访问漏洞

设置StatViewServlet(监控页面)的enabled为 false，即不启动监控页面
或设置监控页面的账密

先查看是否存在这个未授权访问漏洞

发现这里虽然开启了监控页面，但是设置了账密，所以并不存在未授权访问漏洞

密码可爆破

但是发现这个账密很简单，所以这里存在爆破的可能性，于是我去搜索了一下druid有没有f防爆破的措施，结果发现druid默认的登录页面是不需要验证码并且没有防爆破机制的，但有些程序员会自定义开发这个登录页面，添加爆破规则

我们通过查看resource下的static中的静态文件login.html，发现与默认页面相同，判断此处没有二次开发，即存在密码可爆破漏洞

9、easy-captcha

一款好用的Java图形验证码，支持gif、中文、算术等类型，可用于Java Web、JavaSE等项目。

但在网上并没有找到这个组件的公开漏洞，暂时放弃

10、oshi

oshi-core 4.4.2

暂无漏洞

11、Pagehelper

去网上搜了一下，只发现了一个,cve-2022-28111(SQL注入漏洞)

Mybatis-PageHelper是一款分页插件。
Mybatis-PageHelper 1.x.x版本至5.x.x版本存在安全漏洞，该漏洞源于通过orderBy参数存在SQL注入漏洞。

但是经过搜索，该项目中并没有自定义orderBy参数进行排序，所以不存在该漏洞，这个点暂时忽略

12、hutool

版本为5.1.4，找到了几个公开漏洞，整理如下

CVE-2023-42278	Hutool JSONUtil.parse()缓冲区溢出	v5.8.21
CVE-2023-42277	Hutool jsonObject.putByPath缓存区溢出	v5.8.21
CVE-2023-42276	Hutool jsonArray缓存区溢出	v5.8.21
CVE-2023-3276	HuTool SAXParserFactory XML外部实体注入漏洞	< 5.8.19
CVE-2023-33695	Hutool createTempFile函数敏感信息泄漏漏洞	< 5.8.19
CVE-2022-4565	Hutool unzip 拒绝服务漏洞	4.4.2 ~ 5.8.10
CVE-2022-45690	Hutool JSONTokener 拒绝服务漏洞	< 5.8.10
CVE-2022-45689	Hutool JSONObject 拒绝服务漏洞	< 5.8.10
CVE-2022-45688	Hutool toJSONObject 拒绝服务漏洞	5.8.10
CVE-2022-22885	hutool HostnameVerifier 证书验证不恰当	< 5.7.19
CVE-2018-17297	hutool unzip目录遍历任意文件写入漏洞	< 4.1.12

经过测试，发现符合条件的就是Hutool JSONObject 拒绝服务漏洞，因为版本符合，并且该项目也使用了该方法

https://github.com/dromara/hutool/issues/2747

但由于项目使用了全局异常，所以并不能触发该漏洞，结束该漏洞的审计

三、单点漏洞审计

1、SQL注入漏洞审计

本项目使用了Mybatis，来定义SQL。我们主要查看Myabatis中Mapper文件中是否存在使用 $ 拼接SQL语句的情况。使用 $ 是直接拼接SQL语句的，未进行转义。如下

先看看UserMapper文件

可以看到下面的第13行和第16行都使用了$拼接变量，都有可能存在问题，我们挨个分析

1.1、nickName参数like注入

首先分析上面的UserMapper文件的第13行，向上查看根据 select语句的id值追踪该dao层的代码文件。如果在IDEA中安装插件 Free Mybatis plugin 是可以快速进行跳转到代码文件，只需点击左侧绿色箭头即可

点击之后来到UserDao类，如下

可以看到getFuzzyUserByPage这个select语句的参数是一个MyUser实体类，再查看这个实体类，如下

可以看到存在nickName和userName参数，即刚才我们发现的两个问题参数

继续向上追溯，发现UserServiceImpl类使用了这个方法，定位到45行，我们点进去看看，如下

发现该方法的使用位于getAllUserByPage方法内，并且参数来自于getAllUserByPage方法传入的参数，所以我们再去看看getAllUserBypage方法在哪个位置使用的，如下

可以发现直接来到的Controller类中，并且根据这里的几个注解我们可以得出

该方法对应的功能点为”查询用户”
该功能只有拥有”user:list”权限的用户才能使用
该接口在swagger文档中位于“用户列表”中

再看看这里调用的getAllUserByPage方法传入的myUser参数从哪里来的，如下

观察到UserController类被映射到了/api/user接口

所以这里只要用户请求/api/user接口并带上MyUser实体类存在的参数，就会自动将该参数的值赋值给实体类new出来的对象myUser

即我请求127.0.0.1:8080/api/user?username=1时，这里的myUser对象的username会被赋值为1，所以我们请求/api/user传入的nickName参数的值就会被带入问题SQL语句拼接并执行，造成SQL注入

整个流程串下来，确定了漏洞点为 nickName 参数，该参数值来源于查询用户功能。

1.2、userName参数like注入

这个注入同上，位于一个mapper，一个sql语句中，这里就略过了，后面的验证会一同验证

1.3、dictName参数like注入

同上

追踪到实现类，如下

可以看到在实现类的updateParentDeptStatus方法调用了updateDeptStatus方法，我们再追踪到调用updateParentDeptStatus方法的位置，如下

看到是实现类的updateDept方法调用了updateParentDeptStatus方法，继续追踪，来到Controller层

可以看到Controller层代码处理了传入的Mydept对象，处理的过程中调用updateDept方法

同时Mydept实体类代码如下

现在我们理一下上面的输入流转过程，如下

1、用户输入，传入Mydept对象,命名为为dept
2、Controller层调用updateDept(dept)
3、updateDept方法调用updateParentDeptStatus(dept)
4、updateParentDeptStatus方法调用了updateDeptStatus(dept)
5、进入DeptDao
6、Mabatis获取传入的Dept实例的ancestors属性值，并执行对应的update语句

咋一看是不是一个很简单的注入，但是仔细看看第四步的代码，如下

获取传入的dept实例的dept_id属性值，并根据这个id值从数据库获取对应的dept实例，再将数据库获取的dept赋值为dept，即覆盖了传入的dept实例

那这里被覆盖之后的dept的ancestors属性值还会是我传入的dept属性值吗？当然就不是了，而是根据传入的id值从数据库中取出来的

说明了什么？说明针对这个输入流转，我们的ancestors值是不可控的，为什么是“针对这个输入流转呢”？

这里就引出一个平时审计SQL注入漏洞时需要注意的点了，当某个存在SQL注入的参数在当前输入流转不可控时，可以找找其他地方，看能否通过其他功能修改该参数，从而使该参数可控

那怎么找呢？找能够控制该参数的对应方法即可，例如这里参数不可控的原因是因为参数是从数据库取出来的，那我们就可以找找什么地方可以修改数据库中的这个值，即在对应的mapper文件中找找insert语句和update语句

这里共有三个update语句，并没有insert，所以下面我们来逐个看看这三个update语句

1.4.1、第一个update

第一个update语句如下

可以看到这个update语句的作用就是设置指定id的部门的ancestors为指定值

经过追踪，发现该方法传入的ancestors只能是如下

String newAncestors = parentInfo.getAncestors() + "," + parentInfo.getDeptId();

即{上级部门ancestors,上级部门id}

显然我们要控制此处的ancestors为恶意payload是不可能的（因为部门id我们是不可控的），所以这个点放弃

1.4.2、第二个update

第二个update语句如下

将数据库中指定id的dept信息换为传入的dept信息，其中就包含了ancestors参数，所以只要我们能够控制传入dept实例的ancestors属性值，就能够修改数据库中对应的ancestors，造成SQL注入漏洞

所以我们向上追踪一下，先来到Dao层，如下

来到实现类

可以看到实现类中，传入的dept对象如果有上级部门，并且当前dept对象不为空，就会进入到if判断逻辑内部，这里if判断逻辑我们再分析第一个update时也分析过了，会修改我们传入的dept对象的ancestors属性值

如果我们想要插入恶意ancestors，自然就不能让程序修改我们输入的ancestors属性值，也就是不进入这个if判断逻辑，我们传入的dept对象因为要带有恶意ancestors参数值，所以也肯定不会为空，所以我们要尽量保证我们传入的dept对象没有上级部门，这样就不会进入if内部导致输入的ancestors被程序修改

之后程序就会调用updateDept直接替换dept对象的信息到数据库中，我们继续向上追踪，来到Controller层

可以看到Dept对象来源于用户的请求，经过一系列逻辑判断，再调用实现类，所以我们请求该Controller方法映射的接口时，带上ancestors参数即可。并且通过观察该方法的注解，发现该方法对应程序中的“修改部门”功能

所以经过上面的分析，我们确定这个位置是可以控制数据库中的ancestors值的，只需要在“修改部门”的请求中带上ancestors参数，并且当前部门没有上级部门，我们输入的ancestors就会覆盖数据库中ancestors参数值，即实现了ancestors参数可控

又因为刚才我们发现的SQL语句使用$拼接了ancestors参数的值，并且ancestors参数的值是从数据库中获取的

所以判断此处存在SQL注入漏洞，等待验证

1.4.3、第三个update

第三处update语句如下

这个update语句根本没涉及到ancestors参数，所以无需分析

1.5、params.dataScope参数注入

这个就不用多说，总共四处，直接传入params[dataScope]为恶意语句即可

2、XSS漏洞审计

熟悉代码后快速全局搜索是否存在”XSS”，”xssfilter”,以及是否含有常见的对JS标签进行黑名单过滤的工具，如果没有，那大概率是没有进行XSS漏洞的防御的

经过检索，没有发现该项目存在XSS的防御代码，所以大概率是全站XSS，随意验证几个，如下

新增/编辑用户
新增/编辑角色
新增/编辑菜单
新增/编辑部门
新增/编辑岗位
新增/编辑字典
日志记录功能造成的“操作日志”

2.1、layui框架

并且在测试XSS的时候还发现了前端框架为layui，所以针对Layui再进行研究，如下

全局搜索layui-v，如下

得到Layui的版本为5.2.6

在网上并没有检索到layui框架有关xss的问题，师傅分享的Layui的Github上的issue已经被删除

https://github.com/sentsin/layui/issues/711

所以去找了找，发现”疯癫兄”师傅提交的rbac审计作业中截了issue的图，所以能了解到该漏洞的详情，如下

通过上面的issue得到以下结论

1、Layui的2.6.8版本之前Table组件默认不转义HTML，需要转义的话要手动在所有的列定义中加上如下代码

templet:"{{= d.field }}"

2、2.6.8版本之后增加了escape参数，通过配置该参数为true即可对xss相关字符进行过滤
3、2.6.11版本默认table的escape参数为true，即默认开启编码

因为太久没用过layui了，所以对table组件也比较陌生，所以这里查看官方文档简单学习了一下，官方文档链接如下

https://layui.dev/docs/2/table/

Layui的table模块提供的三种渲染方式——方法渲染、自动渲染和静态表格，各有特点，（有兴趣的可以看官方文档学习一下）

我简单整理了一下如何快速查看当前项目用的table模块是哪种渲染方式，都没有的话就是没有用table模块

方法渲染：搜索JavaScript文件中的“table.render”或“layui.table.render”等关键字。
自动渲染：在HTML文件中搜索包含“layui-table”类名的table标签，并检查是否含有“lay-data”属性。
静态表格：在HTML文件中搜索包含“layui-table”类名的table标签，但不包含JavaScript代码或“lay-data”属性。

通过检索，发现js文件中存在”table.render”关键字

所以此处使用了”方法渲染”，来到该位置

通过注释和对代码的分析，发现该功能用于渲染表格的数据内容，又由刚才的issue可知，这里的渲染是默认不编码，所以默认存在XSS漏洞，才会造成前面我们测试XSS时有表格的地方基本都存在XSS漏洞的情况

3、业务逻辑漏洞

（1）先看权限控制

观察是否动态使用了五张表完成了权限与用户，角色的动态绑定，并正确配置

用户表（my_user）
角色表（my_role）
权限表（my_menu）
用户角色关联表（my_role_user）
角色权限关联表（my_role_menu）

可以从数据库中观察到确实使用了对应的五张表

通过对照权限表和角色权限关联表判断开发人员设置的权限是否有不合理的地方

发现开发人员默认给了普通用户删除用户的权限，我们验证一下管理员账户是否有权限配置功能

可以看到开发人员是默认给了普通用户对用户增删改的操作的

我们登录一个普通用户后台看看，如下

发现普通用户登录并看不到其他用户，但是又有对其他用户的操作权限，所以这里存在替换cookie或者改ID来越权操作其他用户

归结原因就是因为管理员默认开启普通用户的操作权限，关闭之后就不会有该问题

注意：我看其他师傅审这个系统时，从代码层面开始，例如

这里是有问题的，这里使用了@PreAuthorize(“hasAnyAuthority(‘user:del’)”)进行权限关联，限定拥有user:del权限的用户才能发起这个请求，如果用户没有 ‘user:del’ 这个权限，Spring Security会拒绝这个请求，不会执行这个方法。，所以这里的代码层面是没有问题的，有问题的只是管理员的错误配置。

（2）看是否使用了成熟的权限校验框架

这里的权限校验框架一般就是Spring security或者shiro

经过前面分析pom文件时观察导入的依赖，得出了该项目是使用了Spring security组件配合jwt来实现动态权限校验的,所以观察SpringSecurityConfig类，这就是Spring security的配置文件，如下

可以看到放行的静态资源中有很多敏感的接口，这就属于配置错误了，所以这里存在接口未授权访问漏洞

（3）看数据是如何鉴权的

分析详细的api和业务系统——看数据是否公开，公开就忽略
看各自的数据获取是否合理——对于私有的数据，是否校验了当前用户登录的身份

4、图形验证码

全局搜索关键字captcha，寻找相关代码，如下

经过检索，发现图形验证码的验证逻辑位于VerifyCodeFilter这个Filter类中

此时就需要我我们来分析一下这个代码逻辑了，经过分析之后简单的流程ruxa

检查请求方法是否为 “POST”，并且请求的URL是否为 “/login”。
从请求中获取会话（session）。
获取用户提供的验证码（captcha）以及会话中生成的验证码。
处理用户提供的验证码为空的情况。如果为空，从会话中删除验证码并返回一个包含错误信息的 JSON 响应。
如果不存在验证码为空的情况，就直接chain.doFilter(request, response)放行了该请求

注意：这里观察到注释内容为判断验证码是否过期和用户输入的验证码与生成的验证码是否匹配，但是这两个判断均被注释了，所以导致即使验证码过期或验证码错误也不会被拦截，即只要验证码不为空就能通过验证码校验机制，猜测是开发人员为了开发方便注释了该代码，但项目上线之后未取消注释，从而造成了验证码绕过漏洞

四、漏洞验证

1、Actuator未授权访问漏洞

直接扫Spring的目录，结果如下（这里使用的工具是Caesar）

其中env包含了了全部环境属性，如下

搜索（），可以看到被星号脱敏的密码，观察其与spring.datasource.password对应，应该是数据库的密码，如果这里/heapdump端点也开放的话，就可以尝试访问*/actuator/heapdump**来获取明文密码。但刚才我们查看配置文件时，显示是没有开放/heapdump，也就无法更深层次的利用

即这里Actuator的未授权漏洞造成的危害仅限于以下三个端点开放造成的信息泄露