实战解析：三大电商系统业务逻辑支付漏洞靶场复现（dami、niushop、cmseasy）
1. 电商支付漏洞实战背景
最近在测试dami、niushop、cmseasy这三个电商系统时，发现了几个有意思的业务逻辑漏洞。这些漏洞看似简单，但危害性不小，攻击者能轻松实现"0元购"甚至"反向提现"。我花了三天时间在本地靶场复现了这些漏洞，下面就把详细过程和防御建议分享给大家。
业务逻辑漏洞不同于SQL注入、XSS这些传统漏洞，它往往是由于系统设计时的逻辑缺陷导致的。比如商品数量可以输入负数、价格能被前端随意修改等。这类漏洞在渗透测试中很容易被忽视，但造成的损失可能比传统漏洞更直接。
2. dami系统漏洞复现
2.1 环境准备
首先从提供的网盘链接下载dami_5.4的安装包，解压后部署到本地PHP环境。我用的PHP版本是7.4，MySQL是5.7。安装过程很常规，按提示配置数据库就行。
注册一个测试账号后，我发现了两个高危漏洞：
2.2 直接修改商品数量
- 随便点开一个商品详情页
- 在购买数量输入框里，把默认的"1"改成"-1"
- 神奇的事情发生了 - 订单总金额显示为"-6000元"
- 随便填个收货地址，选择"站内扣款"提交订单
- 到"在线充值-我要提现"页面一看，账户余额真的多了6000元
这个漏洞的原理是系统没有对商品数量做负值校验，导致"负负得正"的异常情况。更严重的是，系统允许负金额订单使用站内余额支付，形成了完整的攻击链条。
2.3 BurpSuite抓包修改
用新注册的账号测试第二种攻击方式：
- 用BurpSuite拦截购买请求
- 尝试修改price[]参数为1，系统提示余额不足（看来价格校验是有的）
- 转而修改商品数量为-10
- 放行数据包后，订单成功生成
- 检查账户余额，竟然增加了60000元
这个案例告诉我们，仅校验价格是不够的，关键业务参数都需要做完整性校验。dami系统的问题在于：
- 前端输入框没有限制负数
- 后端没有对关键参数做二次校验
- 支付逻辑存在设计缺陷
3. niushop系统漏洞分析
3.1 环境配置
niushop的安装包解压后，需要先访问127.0.0.1/niushop/admin进入后台。默认管理员账号admin/123456，记得安装后要修改。
我在测试时发现了更离谱的漏洞：
3.2 0元购实现
- 前台注册普通用户并登录
- 后台添加测试商品（价格设为100元）
- 前台选择商品点击"立即购买"
- 用BurpSuite拦截请求，将数量改为-1
- 放行数据包后，订单金额神奇地变成0元
- 成功完成"0元购"
niushop的问题在于：
- 订单金额计算完全依赖前端参数
- 后端没有对负数量做校验
- 没有金额下限检查
4. cmseasy系统测试
4.1 安装注意事项
cmseasy对环境要求较高，我测试时发现：
- 必须用PHP5.6版本
- 需要开启curl扩展
- 安装过程会提示配置数据库信息
4.2 数量篡改漏洞
用admin登录后测试第一种攻击：
- 选择任意商品
- 直接在购买页面将数量改为-10
- 点击购买后，账户余额异常增加
4.3 抓包攻击进阶
第二种攻击方式更隐蔽：
- 拦截正常购买请求
- 修改num参数为-2
- 放包后订单金额变为0元
- 账户余额不变，实现真正的"0元购"
cmseasy的特别之处在于：
- 管理员账号也能触发漏洞
- 系统对余额变动有不同处理逻辑
- 漏洞利用方式更灵活
5. 漏洞防御方案
在复现这些漏洞后，我总结了几个关键防御点：
输入校验：对所有用户输入进行严格校验，特别是：
- 商品数量必须为正整数
- 价格参数必须与后端一致
- 关键参数要做签名验证
业务逻辑校验：
- 订单金额必须大于0
- 支付金额必须与实际金额二次核对
- 重要操作要有日志记录
系统设计建议：
- 前后端分离的项目要特别注意参数校验
- 支付流程要加入中间状态校验
- 定期做业务逻辑漏洞扫描
在实际开发中，建议使用成熟的支付SDK，不要自己从头实现支付逻辑。我在项目中就遇到过因为自己实现优惠券逻辑导致的类似漏洞，后来改用支付宝官方SDK后问题就解决了。
6. 测试经验分享
在复现这些漏洞时，有几个实用技巧值得分享：
- 测试数据准备：建议创建专用测试商品，价格设为整数便于计算
- 流量分析技巧：除了BurpSuite，Wireshark有时能发现意外惊喜
- 测试账号管理：为每种测试场景创建独立账号，方便追踪问题
- 环境快照：使用Docker保存测试环境状态，能快速回滚
特别要注意的是，这些测试一定要在授权环境下进行。我有次在客户生产环境做测试，不小心触发了一个逻辑漏洞，导致生成了大量异常订单，还好及时停止了测试。从那以后，我都会先在本地完全复现环境再测试。