RBAC管理系统审计记录

RBAC管理系统审计记录

环境搭建

环境依赖

• Windows
• idea2022
• jdk 8
• RBAC源码
• phpstudy的mysql 5.6.7

简易搭建流程（Windows下）

• 直接使用idea打开项目，然后选中右上角的项目构建
• 项目中有几处需要修改：
  ○ 1、 要开启phpstudy的mysql，然后创建rbac数据库，并将源码中的rbac.sql数据导入进数据库
  ○ 2、在全局中搜索application.yaml文件，修改其中的数据库密码为phpstudy中设置的用户名密码
  ○ 3、使用admin/123456登录炼石计划后台进入系统
  ○ 4、使用admin/admin登录sql监控
  ○ 5、使用idea自动下载系统所需所有依赖包
  ○ 6、 系统访问url：http://127.0.0.1:8088

系统审计

• java代码审计，一般都是基于maven的web项目，然后使用spring框架，或者是基于tomcat的web项目，使用spring框架
• 审计时，要先关注pom.xml文件，这个文件是Maven进行工作的主要配置文件。在这个文件中我们可以配置Maven项目的groupId、artifactId和version等Maven项目必须的元素；可以配置Maven项目需要使用的远程仓库；可以定义Maven项目打包的形式；可以定义Maven项目的资源依赖关系等等。

漏洞审计

SQL注入

• 从pom.xml文件中可以发现是使用了mybatis进行sql语句的操作

mybatis

• MyBatis支持两种参数符号，一种是#，另一种是$。
• 使用参数符号#的句子：
• <select id="selectPerson" parameterType="int" resultType="hashmap"> SELECT * FROM PERSON WHERE ID = #{id}</select>
• MyBatis会创建一个预编译语句，生成的代码类似于
  * // Similar JDBC code, NOT MyBatis…String selectPerson = "SELECT * FROM PERSON WHERE ID=?";PreparedStatement ps = conn.prepareStatement(selectPerson);ps.setInt(1,id);
• 参数会在SQL语句中用占位符”?”来标识，然后使用prepareStatement来预编译这个SQL语句。
• 在默认情况下，MySQL Connector/J只不过是把selectPerson做了一下转义，前后加了双引号，拼接到SQL语句里面，然后再交给MySQL执行。另一种使用参数符号$时，MyBatis直接用字符串拼接把参数和SQL语句拼接在一起，然后执行。这种操作就是十分危险的了，很容易产生sql注入
• 所以对于mybatis进行sql操作的，我们可以直接搜索${来判断

mybatis拼接sql有下面两种方式：

#{} 告诉mybatis创建一个预编译语句（PreparedStatement）参数，在JDBC中，这样的一个参数

在SQL中会由一个"?"来标识，并被传递到一个新的预处理语句中

${} 仅仅是纯粹的string替换，在动态SQL解析阶段将会进行变量替换，类似于直接替换字符串，会

导致SQL注入产生。

一些不能使用#{}的场景：

表名/字段名 如果预编译了，就没法查了

order by/group by

like模糊查询

in

• 直接搜索关键字${
• 所以我们在代码审计阶段进行SQL注入漏洞挖掘时，应关注 xxxMapper.xml 中使用 ${} 凭借SQL的地方。推荐使用搜索关键字符，win快捷键 CTRL+SHIFT+F (PS.设计xml的目的是用作数据交换，当然也可以用作保存数据。xml保存数据具有平台无关，规范化。通过提供方提供的读取程序就可以读取出xml数据。)
• 调出 Find in path ，file mask选择文件夹类型为*.xml，输入关键字符${}（在文件中查找）
• 点击进⼊DictMapper.xml向上找调⽤src/main/resources/mybatis-mappers/DictMapper.xml
• 先双击DictMapper.xml文件定位到关键字，然后跟id=getFuzzyDictByPage到声明处DictDao.java，然后再转到函数引用文件到DictServicelmpl.java，在通过跟踪调用到DictController.java文件

注入点一：/api/dict

 http://127.0.0.1:8088/api/dict?page=1&limit=10&dictName=if(1=1,1,exp(710))

dictName参数为注⼊点

注入点二：/api/user

http://127.0.0.1:8088/api/user?

page=1&limit=10&userName=if(2=2,1,exp(710))&nickName=if(1=1,1,exp(710))
userName和nickname处均存在注入

越权漏洞

越权删用户

• 漏洞代码

@Override  
public int deleteUser(Integer userId) {  
    checkUserAllowed(new MyUser(userId));  
    roleUserDao.deleteRoleUserByUserId(userId);  
    userJobDao.deleteUserJobByUserId(userId);  
    return userDao.deleteUserById(userId);  
}

• 观察这段代码可以发现会先对输入的可控userid进行check，然后会先删除role再删除用户，其中没有任何的其他鉴权
• 跟一下checkUserAllowed()函数到UserServiceImpl.java文件

public void checkUserAllowed(MyUser user) {  
    if (!StringUtils.isEmpty(user.getUserId()) && user.isAdmin())  
    {  
        throw new MyException(ResultCode.ERROR,"不允许操作超级管理员用户");  
    }  
}

• 这里可以发现只要userid不为空或者不是管理员就可以删除，中间也未做其他鉴权判断，这样就导致会产生越权删除其他用户风险