Java代码审计 | 某电商系统 漏洞分析
字数 1746 2025-08-29 08:30:12
Java代码审计:某电商系统漏洞分析教学文档
一、系统概述
starsea-mall 是一套基于Spring Boot 2.X技术栈开发的电商系统,包含两个主要部分:
-
前台商城系统:
- 功能模块:首页登录、商品分类、新品上线、首页轮播、商品推荐、商品搜索、商品展示、购物车、订单结算、订单流程、个人订单管理、会员中心、帮助中心等
-
后台管理系统:
- 功能模块:数据面板、轮播图管理、商品管理、订单管理、会员管理、分类管理、设置等
二、组件安全审计
审计发现系统使用的组件版本及安全情况:
| 组件名称 | 组件版本 | 是否存在历史漏洞 |
|---|---|---|
| mybatis | 2.1.3 | 不存在 |
| springfox-swagger2 | 2.7.0 | 不存在 |
| springfox-swagger-ui | 2.7.0 | 不存在 |
| commons-fileupload | 1.6 | 不存在 |
三、单点漏洞审计与分析
1. 水平越权漏洞
漏洞描述:用户可以通过修改请求中的用户ID参数来访问或修改其他用户的信息。
漏洞位置:/personal/updateInfo接口
攻击步骤:
- 正常登录用户账户
- 抓取修改用户信息的请求数据包
- 修改请求中的
userId参数为其他用户的ID - 成功接管目标用户账户
代码分析:
// 问题代码逻辑
public Result updateUserInfo(UserInfo userInfo, HttpSession httpSession) {
// 从会话中获取当前用户临时信息
UserInfo currentUser = (UserInfo) httpSession.getAttribute("user");
// 直接使用传入的userInfo更新数据库,没有校验传入ID与当前用户ID是否匹配
userInfoService.updateUserInfo(userInfo);
// 更新会话中的用户信息
httpSession.setAttribute("user", userInfo);
return Result.success();
}
修复建议:
- 在更新用户信息前,校验传入的
userId必须与当前登录用户的ID一致 - 从会话中获取当前用户ID,而不是依赖客户端传入的ID
2. 订单状态修改漏洞
漏洞描述:系统仅通过简单的0和1来判断支付状态,攻击者可以绕过支付流程直接修改订单状态为"已支付"。
漏洞位置:/paySuccess接口
攻击步骤:
- 创建一个未支付的订单
- 抓取支付成功的数据包
- 修改支付状态参数为1(已支付)
- 重放请求,订单状态被非法修改
代码分析:
// 问题代码逻辑
public Result paySuccess(String orderNo, Integer payStatus) {
// 仅根据订单号和支付状态更新,没有验证支付凭证
orderService.updateOrderPayStatus(orderNo, payStatus);
return Result.success();
}
修复建议:
- 引入支付凭证验证机制
- 记录支付交易流水号并与第三方支付平台核对
- 支付状态变更应伴随完整的业务逻辑校验
3. 任意文件上传漏洞
漏洞描述:系统仅在前端对上传文件类型进行校验,后端未做任何过滤,导致攻击者可上传任意文件(包括恶意脚本)。
漏洞位置:/upload/file接口
攻击步骤:
- 准备一个恶意文件(如webshell.jsp)
- 拦截上传请求
- 修改文件后缀为允许的类型(如.jpg)
- 成功上传恶意文件
代码分析:
// 问题代码逻辑
public Result uploadFile(MultipartFile file) {
// 没有对文件后缀、内容类型或内容进行校验
String fileName = file.getOriginalFilename();
String filePath = "/upload/" + fileName;
file.transferTo(new File(filePath));
return Result.success(filePath);
}
修复建议:
- 实施白名单机制,只允许特定文件类型
- 校验文件内容而不仅是扩展名
- 将上传文件存储在非Web可访问目录
- 对上传文件重命名,避免目录遍历攻击
- 限制上传文件大小
4. XSS漏洞
漏洞描述:系统在商品信息更新接口中未对用户输入进行过滤,导致存储型XSS漏洞。
漏洞位置:/admin/goods/update接口
攻击步骤:
- 在商品信息字段中插入恶意JavaScript代码
- 提交保存
- 当管理员或其他用户查看该商品时,恶意脚本被执行
代码分析:
// 问题代码逻辑
public Result updateGoods(@RequestBody Map<String, Object> data) {
// 直接使用未过滤的用户输入
goodsService.updateGoods(data);
return Result.success();
}
修复建议:
- 对所有用户输入进行HTML实体编码
- 实施内容安全策略(CSP)
- 使用安全的富文本编辑器并配置XSS过滤规则
- 在输出时进行编码,而不仅是输入时
四、综合安全建议
-
输入验证:
- 实施严格的输入验证机制
- 遵循"最小特权"原则,只接受必要的参数
-
权限控制:
- 实施完善的权限校验机制
- 关键操作需进行二次验证
-
安全编码:
- 避免直接拼接SQL语句
- 使用预编译语句防止SQL注入
- 对敏感操作记录详细日志
-
安全配置:
- 禁用不必要的HTTP方法
- 配置安全HTTP头
- 定期更新依赖组件
-
安全测试:
- 实施自动化安全扫描
- 定期进行渗透测试
- 建立代码审计流程
五、免责声明
- 本文提供的技术信息仅供参考,不构成任何专业建议
- 读者应遵守《中华人民共和国网络安全法》
- 作者及发布平台不对因使用本文信息导致的任何直接或间接责任或损失负责