mall 项目代码审计复盘#

1.1 审计环境#

1.2 项目模块分析#

首先对项目整体架构进行梳理，明确各模块的职责、对外服务端口以及主要依赖。初步模块信息如下。

所有模块均继承根 POM 中的公共依赖，主要包括：

• spring-boot-starter-actuator
• spring-boot-starter-aop
• hutool-all 5.8.40
• lombok 1.18.46

从模块划分可以看出，项目采用多模块架构，将公共能力、安全控制、后台管理、前台业务和商品搜索进行了拆分。其中，mall-security 是认证与授权机制的核心模块，mall-admin 和 mall-portal 则分别承载后台管理与商城交易业务，是本次审计的重点。

1.3 核心框架版本#

1.4 值得关注的第三方依赖链#

在梳理依赖关系时，记录以下值得后续专项排查的依赖组合。本阶段只记录依赖及版本信息，暂不直接据此判定漏洞。

1. mall-portal：支付宝 SDK 依赖链

alipay-sdk-java 引入了以下依赖：

• Fastjson 1.2.83_noneautotype
• OkHttp 3.12.13
• Bouncy Castle bcprov-jdk15on 1.62
• dom4j 1.6.1

其中，项目依赖树中同时存在多个版本的 Bouncy Castle，包括 1.62 与 1.84，后续需要结合实际调用点和依赖解析结果进一步分析。

2. mall-admin：MinIO 依赖链

MinIO 8.6.0 引入了 Guava 33.4.8-jre 和 bcprov-jdk18on 1.84。项目显式排除了 MinIO 原有的 OkHttp 依赖，改用 okhttp-jvm 5.1.0。

3. mall-admin：阿里云 OSS 依赖链

aliyun-sdk-oss 引入了 HttpClient 4.5.13、Jettison 1.5.4 和 JDOM2。其中，HttpClient 4.5.13 与项目中其他位置使用的 4.5.14 存在版本差异。

4. mall-search：Redis 依赖排除

mall-search 显式排除了整个 Redis 依赖链，是当前模块配置中唯一未引入 Redis 的应用模块。

依赖层面的后续审计重点包括：旧版本组件的实际使用情况、依赖冲突、传递依赖是否进入运行时，以及是否存在能够被外部输入触发的危险调用链。

1.5 外部基础设施与配置#

根据项目配置文件，梳理各基础设施在开发环境和生产部署环境中的连接信息。

此外，根 POM 中配置了以下 Docker 构建宿主地址：

docker.host=http://192.168.3.101:2375

该配置指向未启用 TLS 的远程 Docker API，是值得关注的部署安全配置。

1.6 初步审计思路#

综合模块架构、业务特点与第三方依赖情况，mall 是一个基于 Spring Boot 的多模块商城系统，后台鉴权采用 Spring Security 与 JWT，业务侧包含商品、订单、支付、库存、优惠券及会员管理等功能。

据此，确定以下几个主要审计方向：

1. 认证与授权： 检查 JWT 解析与验证、身份创建、角色授权、敏感接口保护及账户状态变更后的 Token 失效机制。
2. 业务逻辑： 优先审计支付、订单、价格、库存和优惠券等与资金及业务状态直接相关的流程，重点检查数据归属、状态转换和金额计算。
3. 第三方组件： 关注 Jackson、SnakeYAML、Fastjson 等组件的具体使用场景，进一步分析是否存在危险反序列化或其他可被外部输入触发的问题。
4. 配置与基础设施： 关注文件上传、对象存储、管理控制台、远程服务接口以及部署配置中的安全风险。

2.1 JWT 过滤器审计#

首先检查 mall-security 模块下的 SecurityConfig，确认系统的安全过滤链配置。

项目采用自定义 JWT 过滤器，并将其添加到 UsernamePasswordAuthenticationFilter 之前。除配置的白名单外，请求需要通过相应的认证与授权检查。白名单路径由配置加载，后续还需要结合具体 Controller 梳理各接口的实际访问要求。

随后定位 JwtAuthenticationTokenFilter，分析其认证处理流程。

整体流程如下：

1. 从请求头中读取 Token。
2. 检查请求头是否包含预期的 Token 前缀。
3. 从 Token 中解析用户名。
4. 判断用户名是否为空，以及当前安全上下文是否已经存在认证信息。
5. 根据用户名调用 UserDetailsService 加载用户信息。
6. 调用 jwtTokenUtil.validateToken(authToken, userDetails) 验证 Token。
7. 验证通过后，创建 UsernamePasswordAuthenticationToken，将用户权限写入认证对象，并设置到 SecurityContextHolder 中。
8. 继续执行后续过滤链。

在这条调用链中，JWT 的签名、用户名与有效期均由相关工具方法处理，初步审计未发现明显的 Token 伪造或绕过问题。

值得注意的是，用户名在过滤器中已经被解析一次，validateToken() 内部又会解析用户名并进行比较。这一过程存在重复解析的可能，但 validateToken() 同时负责其他有效性检查，因此不能简单地将该方法整体视为冗余。

完成过滤器审计后，继续检查敏感路径是否存在未受有效访问控制保护的情况。

2.2 角色与资源关系梳理#

为了判断系统是否存在越权问题，先从数据库 SQL 文件中梳理角色、资源和接口 URL 之间的对应关系。

项目通过数据库中的资源信息进行动态授权，角色与资源的关联关系保存在相应的数据表中，而不是完全依赖 Controller 上的权限注解。

整理得到以下角色与资源映射关系：

系统包含三类管理员角色和普通登录用户；如果将未登录访问者也作为独立的访问主体，则可以从五类访问身份的角度分析其访问边界。

在此基础上，先审计登录和身份创建流程，再对各 Controller 的路由进行归类。

2.3 登录与身份创建流程#

定位 UmsAdminController 中的登录接口，并继续跟踪对应的 Service 实现。

登录流程主要包括：

1. 接收客户端提交的用户名与密码。
2. 根据用户名加载用户信息。
3. 使用密码编码器比对密码。
4. 检查账户状态。
5. 根据用户信息及其权限构建认证对象。
6. 生成 JWT，并将 Token 返回客户端。

继续检查 loadUserByUsername() 及其相关方法。用户信息首先尝试从缓存获取，缓存未命中时再从数据库查询；获取用户信息后，系统进一步加载角色与资源，并将相应权限放入 UserDetails。

随后检查 generateToken()。Token 的主要声明包括用户名和创建时间，并根据配置生成相应的过期时间。

截至此处，身份创建、密码比对、权限加载及 Token 生成流程均已完成初步审计，暂未发现明显的认证绕过问题。

不过，身份创建只是认证生命周期的一部分。用户被禁用、删除或撤销权限之后，已签发的 Token 是否能够及时失效，同样属于认证机制必须覆盖的范围。

2.4 后台管理接口与访问控制映射#

接下来整理 mall-admin 模块的 Controller 路由，重点识别匿名接口、动态授权接口以及可能存在配置缺失的敏感接口。

mall-admin 模块包含 31 个 Controller。根据白名单配置、角色资源关联关系及实际路由，整理如下。

其中，/minio/delete 和 /aliyun/oss/callback 在动态授权过程中未匹配到对应资源。根据 DynamicAuthorizationManager 对空权限集合的处理逻辑，这类请求将被拒绝，因此超级管理员也无法通过现有动态授权规则访问这些路径。

通过以上整理，可以从 URL 级别了解各角色的访问范围，并对敏感接口的实际保护情况进行核对。

这里还发现两个值得进一步检查的匿名接口：/minio/upload 和 /aliyun/oss/policy。前者涉及文件上传，后者涉及对象存储上传策略，需要分别审计其上传限制、存储权限和策略生成逻辑。

2.5 账户禁用与 JWT 生命周期审计#

完成接口权限梳理后，进一步检查账户状态变化能否及时影响现有 Token。

此前已经确认，登录时会检查用户状态；但登录校验通过，并不意味着账户在整个 Token 有效期内始终处于有效状态。因此，需要回到 JwtAuthenticationTokenFilter，进一步分析每次请求中的身份状态检查。

在 v1.0.3 对应的实现中，过滤器会从 Token 中获取用户名，再加载用户信息，随后调用 validateToken()。

问题在于，该版本的 validateToken() 主要检查以下内容：

• Token 中的用户名是否与加载出的用户信息一致；
• Token 是否已经过期。

但该方法没有检查用户本身的启用状态。因此，如果管理员登录后获得了 Token，之后账户被禁用，已有 Token 仍可能在有效期内通过验证，直到 Token 自身过期才失效。

继续检查 UmsAdminController 中的 /admin/refreshToken，发现其调用 adminService.refreshToken()，而服务方法进一步调用 jwtTokenUtil.refreshHeadToken()。

该刷新逻辑主要验证原 Token 的格式、签名和有效期，并根据创建时间判断是否需要刷新。由于刷新流程没有重新校验用户当前的账户状态，已被禁用的账户仍可能在原 Token 到期前持续刷新 Token。

由此形成完整的问题链：

1. 用户在账户正常时登录，取得有效 Token。
2. 管理员将账户禁用。
3. 请求过滤器未在 Token 验证阶段检查账户是否仍启用。
4. 用户继续使用尚未过期的 Token 访问业务接口。
5. 在 Token 有效期内调用刷新接口，还可能延长其可使用时间。

审计结论： 账户禁用机制未能有效约束已签发 Token 的使用与刷新，导致账户状态变更后，用户身份不能及时失效。

2.6 后台模块阶段性结论#

后台模块审计主要覆盖了 JWT 过滤器、登录与权限加载、角色和资源映射、Controller 路由保护，以及账户禁用后的 Token 生命周期。

本阶段未发现明显的基础认证流程绕过问题，但发现账户状态检查与 Token 刷新机制之间存在缺口。另外，匿名文件上传与对象存储策略接口值得继续深入检查。

完成后台部分后，将审计重点转向 mall-portal，集中检查商城交易链路中的身份归属、金额计算、订单状态转换、库存一致性及优惠券核销。

3.1 审计范围与业务流程梳理#

mall-portal 是前台商城模块，承载购物车、商品、会员、订单、支付及优惠券等业务。本阶段优先关注以下资源：

• 商品及商品价格；
• 购物车与购买数量；
• 订单创建、取消与支付；
• 库存锁定和扣减；
• 优惠券领取、使用与核销；
• 退单及退款流程；
• 订单、购物车等业务对象的归属校验。

审计前先梳理一次典型购物流程：

选择商品 → 加入购物车 → 生成订单 → 发起支付 → 支付结果回调 → 订单进入已支付状态 → 商品等待发货及后续履约。

实际业务中，还涉及优惠券抵扣、库存锁定、支付超时取消、退单和退款等分支。

因此，本阶段不只检查单个接口的参数校验，而是沿着关键业务数据的传递路径追踪其来源、计算过程和最终影响。

3.2 支付流程审计#

3.3 订单接口审计#

3.4 购物车归属校验审计#

3.5 退单与退款业务审计#

在退单模块中，发现部分处理逻辑直接接收客户端提交的退单信息，未对关键业务字段进行充分校验。随后继续追踪至后台退单管理相关流程，发现退款处理涉及订单金额等参数。

这部分需要重点关注：

• 退单申请是否属于当前会员；
• 申请关联的订单是否属于当前会员；
• 当前订单状态是否允许退单；
• 申请退款金额是否超过可退款金额；
• 退款金额是否来自服务端可信的订单与支付数据；
• 管理员审批通过后，实际退款金额是否经过二次校验。

虽然退款需要管理员审批，但审批环节并不能代替服务端对退款金额的约束。若关键金额参数仍可由客户端控制，就应继续检查审批通过后实际退款的执行路径。

因此，退单审计的核心不仅是检查“是否需要管理员同意”，还需要确认申请数据、审批结果和实际退款金额之间的一致性。

3.6 购物车数量校验与库存逻辑审计#

在检查价格参数后，继续沿订单创建链路追踪购买数量。因为订单金额通常与商品价格和购买数量直接相关，所以数量异常同样可能影响交易金额、库存及订单状态。

1
public int add(OmsCartItem cartItem) {
2
    UmsMember currentMember = memberService.getCurrentMember();
3
    cartItem.setMemberId(currentMember.getId());
4
    cartItem.setMemberNickname(currentMember.getNickname());
5
    cartItem.setDeleteStatus(0);
6
    // 后续查询或创建购物车记录
7
}

1
private boolean hasStock(List<CartPromotionItem> cartPromotionItemList) {
2
    for (CartPromotionItem cartPromotionItem : cartPromotionItemList) {
3
        if (cartPromotionItem.getRealStock() == null
4
                || cartPromotionItem.getRealStock() <= 0
5
                || cartPromotionItem.getRealStock()
6
                    < cartPromotionItem.getQuantity()) {
7
            return false;
8
        }
9
    }
10
    return true;
11
}

1
private BigDecimal calcTotalAmount(List<OmsOrderItem> orderItemList) {
2
    BigDecimal totalAmount = new BigDecimal("0");
3
    for (OmsOrderItem item : orderItemList) {
4
        totalAmount = totalAmount.add(
5
            item.getProductPrice().multiply(
6
                new BigDecimal(item.getProductQuantity())
7
            )
8
        );
9
    }
10
    return totalAmount;
11
}

1
oms_order:
2
id=80
3
total_amount=-2699.00
4
pay_amount=-2699.00
5
status=0

1
stock = stock - #{productQuantity}

3.7 优惠券业务审计#

在检查完价格与数量后，继续分析订单创建请求中剩余的金额相关参数——couponId。

优惠券涉及可抵扣金额、使用门槛、会员归属和使用状态，因此需要重点检查优惠券是否可用，以及核销操作能否抵御并发竞争。

1
private void updateCouponStatus(
2
        Long couponId,
3
        Long memberId,
4
        Integer useStatus) {
5

6
    // 查询第一张优惠券
7
    SmsCouponHistoryExample example =
8
        new SmsCouponHistoryExample();
9

10
    example.createCriteria()
11
        .andMemberIdEqualTo(memberId)
12
        .andCouponIdEqualTo(couponId)
13
        .andUseStatusEqualTo(useStatus == 0 ? 1 : 0);
14

15
    List<SmsCouponHistory> couponHistoryList =
16
        couponHistoryMapper.selectByExample(example);
17

18
    if (!CollectionUtils.isEmpty(couponHistoryList)) {
19
        SmsCouponHistory couponHistory =
20
            couponHistoryList.get(0);
21

22
        couponHistory.setUseTime(new Date());
23
        couponHistory.setUseStatus(useStatus);
24

25
        couponHistoryMapper.updateByPrimaryKeySelective(
26
            couponHistory
27
        );
28
    }
29
}