大米CMS支付漏洞复现报告

大米CMS支付漏洞复现报告

---

漏洞编号：CNVD-2018-18085、CNVD-2018-17457

准备阶段：

工具：

• PHPstudy（小皮面板）
• Burp Suite（抓包工具）

源码：

• 大米CMS5.4版本

环境搭建：

1.使用小皮面板快速搭建大米cms靶场，打开靶场

2.先进行注册登录

• user：admin666
• password：admin666
• email：26xxxxxx29@qq.com

注册信息可以随便填写

【PS】：尽管是靶场，但是你注册的信息仍然会存储在该靶场的数据库（可以下载），下次开启靶场依旧可以登录，无需注册

3.登录后填写相关信息避免后续支付时需要多次填写信息

4.在FirFox浏览器配置Burp Suite代理

到此准备工作完成

---

漏洞复现阶段

1.进入购物界面

---

2.打开Burp Suite代理，选择“立即购买”，然后进行抓包

---

漏洞分析：

HTTP明文传输漏洞

由于在小皮面板中搭建的靶场基于HTTP协议实现，未启用HTTPS加密传输，因此可能存在中间人攻击等安全隐患。

而如果是真实网站：可利用协议降级攻击导致HTTPS-->HTTP

【拓展】：协议降级攻击

工具：sslstrip2

原理：

---

参数分析：

• id=127
• name=%E5%A4%A7%E7%B1%B3%E6%B5%8B%E8%AF%95%E4%BA%A7%E5%93%81【“大米测试产品”】
• qty=1
• price=6000

在这里我们可以清晰可见的发现，几个比较重要的参数：商品id，商品数量（qty），商品价格（price）。

支付漏洞最常见的一种攻击方式：参数篡改

---

参数篡改（前端/传输层）

参数篡改类型：

金额/数量篡改：抓包修改price、quantity参数（如改为负值或0.01元），绕过支付校验。

优惠券/积分溢出：修改优惠券面值为大于商品价格的值，或重复使用同一优惠券（复用漏洞）。

支付状态伪造：将支付结果参数由failed改为success，欺骗系统确认付款。

篡改对象	示例参数	攻击效果
金额	amount=100 → amount=0.01	低价购买高价商品
数量	quantity=1 → quantity=-5	总价负数导致余额增加
优惠券ID	coupon_id=1 → coupon_id=9	使用未授权的满减券
支付渠道	channel=alipay → test	调用测试接口实现零元支付

---

3.对参数进行篡改

（1）对参数qty进行篡改

篡改效果：

---

（2）对参数price进行篡改

篡改效果：

---

（3）对参数id进行篡改

篡改效果：

【PS】：攻击者通过将订单中的商品ID替换为数据库中存在的其他高价商品ID，利用后端未校验用户权限或订单归属的缺陷，实现以低价商品价格结算高价商品的交易欺诈。

---

漏洞原理：

1.前端验证不充分

表现：仅依赖前端JS校验参数（如金额、数量），未在服务端二次验证。攻击者通过禁用JS或修改请求包绕过限制。

案例：某电商平台允许将商品数量改为负数（如-5），后端未校验导致订单金额异常增加。

2.后端校验缺失

表现：服务端未对关键参数（如订单ID、支付状态）进行数据库比对，直接信任客户端提交的数据。

案例：攻击者篡改支付状态参数（status=success）直接标记订单为已支付，造成资金损失

3.加密与签名缺陷

表现：敏感参数（如金额、优惠券ID）未加密或签名验证不严格，攻击者可篡改数据包内容。

案例：某支付系统使用HTTP明文传输支付金额，攻击者通过中间人攻击（MITM）将100元改为0.01元

4.接口与协议漏洞

表现：支付接口暴露或存在逻辑缺陷（如未校验接口白名单），攻击者可替换接口地址劫持交易。

案例：篡改pay_api_url参数指向虚假支付接口，用户付款后资金未到账

---

4.完整攻击链

（1）查看个人账户余额（6000元）

（2）选择订单

【PS】：选择“站内扣款”，因为本靶场，并未调用API接口跳转外部应用支付

（3）提交订单，并且进行抓包

（4）篡改参数

篡改参数pty为-1

（5）完成订单

（6）查看成效

金额从6000-->12000

【PS】：由于篡改金额以及数量等参数的原理都是相同的，这里不做过多演示

总结

本次漏洞复现验证了大米CMS 5.4版本支付系统的多重安全缺陷，攻击者可通过以下链条实现非法牟利：

核心攻击链：

1. 协议层缺陷
   基于HTTP明文传输的架构使攻击者可实施中间人攻击（MITM），结合sslstrip2等工具强制降级HTTPS为HTTP，窃取支付敏感参数。

2. 参数篡改突破

   • 金额/数量篡改：将price从6000元改为0.01元，或qty设为-5，导致系统计算逻辑失效
   • 商品ID替换：通过id参数切换高价值商品，实现低价购买高价商品
   • 支付状态伪造：篡改status参数可直接标记订单为已支付

3. 业务逻辑漏洞
   后端完全信任前端传参，未对支付渠道、优惠券使用次数、订单归属等关键字段进行二次校验，导致攻击者可操控支付结果与资金流向。

危害评估：

• 直接经济损失：通过负数金额操作可实现账户余额异常增长（如案例中将6000元变为12000元）
• 数据完整性破坏：篡改交易记录影响审计追踪
• 信任体系崩塌：用户支付信息被窃取或篡改将导致平台信誉受损

防御建议：

1. 传输层加固
   全站启用HTTPS并配置HSTS，部署WAF拦截SSL剥离攻击

2. 参数防御矩阵

   • 输入验证：对所有支付相关参数（amount/quantity/coupon_id等）进行前后端双重校验
   • 输出编码：防止参数注入攻击
   • 签名机制：对关键请求添加时间戳+数字签名（如HMAC-SHA256）

3. 业务逻辑强化

   • 实施金额范围校验（如设定最小值≥0.01）
   • 引入风控引擎监控异常交易模式（如高频小额测试订单）
   • 订单归属校验：绑定用户Session与订单ID

4. 接口安全增强

   • 白名单过滤支付回调接口
   • 对第三方支付网关采用双向认证
   • 日志监控：记录支付参数变更操作并设置告警阈值

修复验证方法：
使用Burp Repeater重放攻击载荷，观察后端是否返回参数校验错误提示（如"Invalid price format"或"Insufficient balance"），若仍执行支付则需继续优化防护策略。

（注：本报告基于靶场环境复现，实际攻击需承担法律责任。建议在授权范围内开展渗透测试。）

道德与法律约束
文中涉及的网络安全技术研究均遵循 合法合规原则：
1️⃣ 所有渗透测试仅针对 本地授权靶机环境
2️⃣ 技术演示均在 获得书面授权的模拟平台 完成
3️⃣ 坚决抵制任何未授权渗透行为

法律追责提示
对于任何：
✖️ 盗用文章内容
✖️ 未授权转载
✖️ 恶意篡改原创声明
本人保留法律追究权利。