Java代码审计之新蜂管理商城系统

1. 第三方组件漏洞审计

maven看pom.xml，整理出来第三方组件以及版本号，并说明存在漏洞组件

2. 组件漏洞代码审计

经过分析新蜂商城系统的 pom.xml，发现实际引入第三方依赖并不多。虽然有些依赖存在漏洞，但没发现实质性危害，并且也没有什么有趣的地方，故组件漏洞代码审计部分省略。

3. 单点漏洞代码审计

下面进入单点漏洞代码审计部分，所谓的单点漏洞是指的代码中存在特定的漏洞点。通过该漏洞点可以实现一些渗透攻击，进而对系统造成不同程度的危害

3.1 后台 SQL 注入漏洞代码审计

前台也有个sql注入，比后台的还要简单就不写了

在pom.xml文件中发现该系统使用了Mybatis持久层框架（第三方依赖）

在 Mybatis 中有两种常用的拼接 SQL 语句的符号，即 $ 和 #

方式一：
#{} ：告诉 MyBatis 创建一个预编译语句（PreparedStatement）参数，在 JDBC 中，这样的一个参数在SQL 中会由一个“?”来标识，并被传递到一个新的预处理语句中
但order by/group by、like模糊查询、in等是不能使用#{}进行sql语句的使用
方式二：
${}： 仅仅是纯粹的 string 替换，在动态 SQL 解析阶段将会进行变量替换，直接替换字符串，会导致SQL注入产生。
因此，我们在代码审计阶段进行SQL注入漏洞挖掘，应关注 xxxxMapper.xml 中使用 ${} 拼接SQL的地方，全局搜索关键字符。

3.1.1 分析 NewBeeMallGoodsMapper.xml 映射文件

发现了有四处使用了${ } 拼接sql语句的地方。

从第一个开始看，双击进去，发现漏洞点

1
2
3
4
5
6
<if test="goodsName!=null and goodsName!=''">
条件判断:仅当 goodsName 既不为 null 也不为空字符串时，才会在 SQL 中添加该条件

and goods_name like CONCAT('%','${goodsName}','%')
使用 SQL 的 CONCAT 函数拼接通配符 %，实现模糊匹配。例如：
若 goodsName 为 "手机"，则拼接后的条件为 like '%手机%'，可匹配包含 "手机" 的任意字符串

3.1.2 逆向追踪到映射接口

可以使用Free Mybatis plugin插件（点击左侧箭头），也可以全局搜索对应的ID值，这里使用的市插件的形式。

在 Mybatis 中 XXXMapper.xml 和 XXXMapper.java 的作用:

1
2
3
4
5
XXXMapper.xml:
	这是映射器（Mapper）文件，用于定义 SQL 查询语句和映射关系。它包含了各种 SQL 语句和对应的参数映射、结果映射等配置信息。 xxxmapper.xml 文件中的 SQL 语句可以通过命名空间和标识符来唯一标识，并与 Java 代码中的对应映射器接口关联起来。这个文件通常是使用 XML 格式编写的。

XXXMapper.java:
	这是映射器接口，用于定义数据访问的方法。映射器接口中的方法通常对应于xxxmapper.xml 文件中定义的 SQL 查询语句。通过映射器接口，Java 代码可以调用数据库操作，而不需要直接编写和管理 SQL 查询语句。MyBatis 会在运行时自动实现这些接口的具体实现。映射器接口通常使用 Java 接口的形式编写。

进入 NewBeeMallGoodsService 文件中

3.1.3 继续逆向追踪 ，查看谁调用了 getNewBeeMallGoodsPage 方法：

3.1.4 分析 NewBeeMallGoodsController 中list的代码

首先，点击第 134 行中 pageUtil，该参数来自第 133 行，通过 PageQueryUtil 类创建一个 pageUtil 对象，传入 params 作为参数。PageQueryUtil 是作者自定义的工具类，是用于处理分页相关的操作。

然后，点击 133 行中 params，可以看到该参数来自第 129 行，是一个 Map 对象，可以简单理解为它需要从请求中获取参数。

最后，整理代码信息可以的到接口路径为 /goods/list ，请求为 GET 方法，是个列表功能，根据代码路径来看应该是后台功能，这么看来我们找到了漏洞前端功能点。

有时 SQL 注入防范代码会在过滤器和拦截器中体现，但查看该项目时，并没有发现相关防护代码

3.1.5 漏洞验证：

把抓取到的请求包放到demo文件中，使用sqlmap的-r参数进行验证

3.2 前台越权漏洞验证

注册两个用户

A用户：先进行修改，并进行抓包，发现userId是9

B用户：在进行修改，抓包时发现userId是12 ，进行改包改为userId=9 ，且地址改为天津

在登录到A用户时，发现数据被更改成功了

在代码中全局搜索接口 /personal/updateInfo （请求包中的路径）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    @PostMapping("/personal/updateInfo")
    @ResponseBody
    public Result updateInfo(@RequestBody MallUser mallUser, HttpSession httpSession) {
        NewBeeMallUserVO mallUserTemp = newBeeMallUserService.updateUserInfo(mallUser,httpSession);
        if (mallUserTemp == null) {
            Result result = ResultGenerator.genFailResult("修改失败");
            return result;
        } else {
            //返回成功
            Result result = ResultGenerator.genSuccessResult();
            return result;
        }
    }
}

**第一步：**分析第 116 行，通过方法名也可以看出这是更新用户信息的方法，其中传入了 mallUser 和 httpSession 参数，而这两个参数来自用户， MallUser mallUser 表示要更新的用户对象，也就是接受用户信息的实体类， HttpSession httpSession 表示当前会话的 HttpSession 对象。

跟进 MallUser 查看，主要定义了以下内容，其中有个 userId

**第二步：**返回到 PersonalController 层，Ctrl 加鼠标左键点击第 116 行的updateUserInfo 跟进该方法，最终跳转到了 NewBeeMallUserService 层

击左侧按钮，进行跟进到 NewBeeMallUserServiceImpl 层，updateUserInfo 方法具体代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Override
public NewBeeMallUserVO updateUserInfo(MallUser mallUser, HttpSession httpSession) {
    MallUser user = mallUserMapper.selectByPrimaryKey(mallUser.getUserId());
    if (user != null) {
        user.setNickName(mallUser.getNickName());
        user.setAddress(mallUser.getAddress());
        user.setIntroduceSign(mallUser.getIntroduceSign());
        if (mallUserMapper.updateByPrimaryKeySelective(user) > 0) {
            NewBeeMallUserVO newBeeMallUserVO = new NewBeeMallUserVO();
            user = mallUserMapper.selectByPrimaryKey(mallUser.getUserId());
            BeanUtil.copyProperties(user, newBeeMallUserVO);
            httpSession.setAttribute(Constants.MALL_USER_SESSION_KEY, newBeeMallUserVO);
            return newBeeMallUserVO;
        }
    }
    return null;
}

**第三步：**分析实现层代码具体做了什么操作

第73 行，根据根据用户 ID 主键查询用户信息，跟进 selectByPrimaryKey 通过 MallUserMapper.java 接口跳转到 MallUserMapper.xml 映射器代码中。可以看到，通过限制 userId 在tb_newbee_mall_user 表中查询用户信息。也就是说，我的 userId 是 10，则最终查询语句如下，代码如下图所示：

1
select refid="Base_Column_List"(在上面定义了具体是哪些列) from tb_newbee_mall_user where user_id = 10；

总结来说，第 73 行的作用是通过 ID 查询用户信息并赋值给 user。

第 74 ~ 77 行，如果 user 不为 null，进行了三个 set 操作，其中传入的参数是来自 mallUser。也就是说，将查询到的用户信息中的内容设置成了用户输入的内容了

78 行是关键，通过调用 mallUserMapper.updateByPrimaryKeySelective(user) 方法，将更新后的用户信息保存到数据库。如果更新操作影响的行数大于 0，则执行下面的代码块。我们跟进该方法，通过 MallUserMapper.java 接口跳转到 MallUserMapper.xml 映射器代码中。在这里面我们主要更新了nick_name，address 以及 introduce_sign 这三个是我们传入的参数，不为 null

第 79 ~ 83 行，是上面代码判断操作是否大于 0，符合该条件则进入这几行代码，我们更新个人信息是否符合这个条件的。这几行代码大致意思是，获取更新的用户信息，然后返回更新成功的响应。

**第四步：**整个流程我们追踪完了，总得来说，就是通过传入的 userId 获取用户信息后进行信息更新操作。整个流程没有任何权限校验，没有判断 userId 所属关系，进而造成了越权漏洞。

3.3后台权限绕过漏洞代码审计

发现后台系统身份验证拦截器 AdminLoginInterceptor.java 存在权限绕过漏洞

洞代码位于： src/main/java/ltd/newbee/mall/interceptor/AdminLoginInterceptor.java

漏洞主要发生于第 23 行和第 24 行，下面我们分析下漏洞成因。

首**先，**关键点是第 23 行，使用了 request.getRequestURI() 方法获取路径。如果使用该方法获取的路径进行权限判断是极易出现权限绕过漏洞的。简单来说， getRequestURI 方法返回的路径是未经过服务器端处理的原始路径，可能包含特殊字符或路径跳转，从而绕过服务器端的安全控制。

**其次，**第 24 行使用了 uri.startsWith(“/admin”) 判断 Uri 路径中是否以 /admin 开头，以及获取并判断Session 中的 loginUser 属性是否为 null，两个条件 && 在一起结果为 True 的话进入条件代码，提示需要登录并跳转到后台登录页面中。

既然这样，我们知道 a && b 需要两者都为 True 整体则为 True 才会进入条件判断代码中，如果另其中一个条件为 False 则整体就为 False，就不会进入条件判断中去了。这两个条件中，Session 部分我们是没办法操纵的。但 uri.startsWith(“/admin”) 这个条件我们可以搞点小破坏，前面提到了 uri 是使用的 getRequestURI 方法获取的原始路径，那么我们可以找一些特殊字符绕过路径判断，并且不影响整体接口，比如：分号 ; ，正斜杠 / 等等。

**最终，**构造结构路径为 /;/admin/test 或 ///admin/test ，这样路径就不是以 /admin 开头了，并且该路径不会影响结构访问，实现了权限绕过

绕过技巧：

分号绕过 多/绕过 编码绕过admi%6e 等

https://www.cnblogs.com/nice0e3/p/14801884.html

复现步骤一：

复现步骤二：

复现步骤三：

绕过1：分号绕过

绕过2：多斜线绕过：

绕过3：编码绕过

Java安全
#Java #项目练习
Java代码审计之新蜂管理商城系统
http://example.com/2025/06/14/Java代码审计之新蜂管理商城系统/
作者
XCDH
发布于
2025年6月14日
许可协议