文章总结： 本文解析优惠券叠加漏洞这一SRC高危业务逻辑漏洞，指出根因是后端信任前端限制且缺少数量校验。文章给出原始请求报文、危险PHP代码示例及修复方案，并建议通过抓包修改参数为数组进行测试，强调所有业务校验必须放在后端执行。 综合评分： 85 文章分类： 漏洞分析,SRC活动,WEB安全,实战经验
优惠券叠加漏洞：很多大厂都踩坑的业务逻辑深坑
原创
网安学习室 网安学习室
网络安全学习室
2026年9月28日 10:14 湖南
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
这是 SRC 高频高危业务漏洞，不是 SQL 注入、XSS 这类传统漏洞。开发大多认为优惠券只能单张使用，却忽略前端校验可绕过，攻击者组合多张券实现巨额优惠。本文拆解原理、原始请求报文、危险源码、修复方案与测试思路。
很多人挖洞总盯着 SQL、XSS，却忽略业务逻辑漏洞才是 SRC 赏金大户。 传统漏洞靠 Payload 触发，而业务逻辑漏洞，本质是业务规则被开发者默认信任前端，校验逻辑写在了浏览器，后端缺少强校验。优惠券叠加绕过就是典型代表。
一、漏洞场景
平台业务规则：一笔订单仅允许使用 1 张优惠券。 前端页面限制下拉框只能选择一张券，正常用户无法多选。但前端限制只是展示层，抓包修改请求，一次性传入多张优惠券 ID，后端未做数量校验，全部核销抵扣。 举个实战场景： 商品总价 1000 元，攻击者同时传入 5 张 200 元优惠券，订单直接抵扣 1000 元，0 元下单。
二、原始请求报文
POST /api/order/create HTTP/1.1
Host: test-src.com
Content-Type: application/json
Authorization: Bearer xxxxx
{
"goods_id": "10086",
"num": 1,
"coupon_id":["1001","1002","1003","1004","1005"]
}
正常请求："coupon_id":["1001"]，仅传单张券 ID。 修改后，数组传入多张券，后端循环遍历数组，依次核销每张优惠券，累加优惠金额。
三、存在漏洞的后端伪代码（PHP 示例）
// 危险代码
$couponList = $_POST['coupon_id'];
$totalDiscount = 0;
foreach($couponList as $cid){
$coupon = getCouponById($cid);
// 只校验优惠券是否有效、是否过期，没有校验订单已使用券数量
if($coupon['status'] == 1 && $coupon['expire_time']>time()){
$totalDiscount += $coupon['discount'];
useCoupon($cid,$orderId); //核销优惠券
}
}
$realPay = $orderAmount - $totalDiscount;
漏洞根因：代码只校验单张券有效性，没有增加约束：同一订单最多允许核销一张优惠券。前端做限制，后端完全信任传入的数组。
四、修复代码示例
$couponList = $_POST['coupon_id'];
// 业务规则：限制单订单最多1张优惠券
$maxCoupon = 1;
if(count($couponList) > $maxCoupon){
return "同一订单只能使用一张优惠券";
}
$totalDiscount = 0;
foreach($couponList as $cid){
$coupon = getCouponById($cid);
if($coupon['status'] == 1 && $coupon['expire_time']>time()){
$totalDiscount += $coupon['discount'];
useCoupon($cid,$orderId);
}
}
$realPay = $orderAmount - $totalDiscount;
核心新增：接收参数第一步，先判断优惠券数组长度，超出业务数量直接拒绝。
五、实战测试思路 & 踩坑点
- 抓下单接口，寻找 coupon 相关参数，观察是单个字符串还是数组；
- 如果是单个值，尝试改成数组，批量塞入多个券 ID；
- 额外测试边界：不同类型券（满减券 / 折扣券）是否能叠加；
踩坑提醒：很多平台做了同类型券限制，但不同类型优惠券没有互斥校验，依旧可以叠加。这种场景更容易被忽略，赏金往往更高。
六、漏洞危害总结
- 小额场景：恶意用户薅平台大量补贴，造成资金损失；
- 高危场景：批量注册账号领券，叠加后 0 元下单商品，形成批量薅羊毛；
- 很多企业安全扫描工具扫不出这类漏洞，自动化工具不会理解业务规则，只能靠人工业务逻辑测试。
业务逻辑漏洞总结
业务逻辑漏洞没有统一 Payload，核心就是打破业务既定规则。记住一条铁律：任何前端的限制，都不能信任。所有业务校验，必须放在后端执行。 很多新人挖不到高价值漏洞，就是习惯依赖扫描器，忽略业务流程里的规则校验缺陷。
网络安全 #SRC挖洞 #业务逻辑漏洞 #web安全 #漏洞科普
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：网络安全学习室 网安学习室 网安学习室《优惠券叠加漏洞：很多大厂都踩坑的业务逻辑深坑》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论