【SRC】白嫖豪华客房！某平台520开房活动存致命缺陷 可无限刷取免房券

漏洞概述：

在小程序520/521营销活动中发现优惠券领取逻辑缺陷，攻击者可通过篡改活动ID参数绕过领取次数限制，实现以下风险：

1. 单用户突破"每人限领1张"规则重复领取
2. 通过ID遍历获取未授权的高价值优惠券（含免房券）
3. 耗尽活动预算导致正常用户无法参与

漏洞复现步骤

1. 访问活动入口

• 打开小程序→进入"520限定活动"页面

1. 正常领取流程

   {"activityId":273,"couponId":131}
   

• 已领取用户会收到{"code":400,"msg":"领取失败"}响应

• 点击领取按钮（活动ID=273，关联优惠券ID=131）

• 抓包捕获请求：POST /api/coupon/get

再次抓包，将 activityId 修改为 271、此处的逻辑就是活动 273 对应优惠券 131，我通过抓包修改活动 273 为 271，去绕过限制领取优惠券 131，如下图，成功领取了，也就是绕过每个人只能领取一次的限制.

查看我的卡包，关注该src有段时间了，发现该src部分活动存在优惠卷领取上限，即最多发放固定数量的优惠卷，也就是说这个绕过可以让一个用户将所有优惠券都领完。导致其他用户无法正常领取

通过遍历 couponActivityId，我还领取到了免房券

1. 绕过逻辑验证

• 修改请求参数activityId=271重放请求
• 服务端返回{"code":200,"msg":"领取成功"}
• 验证：在卡包中确认新增优惠券131

• 遍历activityId参数（271-280范围）
• 成功获取到免房券（ID=xxx）等高价值凭证

漏洞原理分析

1. 服务端校验缺陷

• 仅校验用户是否领取过特定activityId，未建立活动与优惠券的强制绑定关系
• 未对请求参数进行业务逻辑校验：couponId与activityId的映射关系缺失

• 未实施请求签名机制，允许客户端任意修改活动参数
• 未对高价值券设置独立风控策略（如人脸核身、支付密码验证）

• 优惠券发放总量控制仅依赖前端提示，服务端未做最终校验

影响评估

风险等级：高危
可能造成：

• 营销活动预算超支（单用户可耗尽所有优惠券库存）
• 免房券等核心资产被恶意套取
• 用户投诉引发的品牌信誉损失
• 黑产批量刷券导致的直接经济损失

修复建议

1. 服务端强化校验

   # 伪代码示例
   defget_coupon(activity_id, coupon_id):
   # 验证活动与优惠券的绑定关系
       valid = db.query("SELECT id FROM activities WHERE id=? AND coupon_id=?", 
                       [activity_id, coupon_id])
   ifnot valid:
   return error("非法请求")
   
   # 校验用户领取次数(基于优惠券维度)
       received = db.query("SELECT count(*) FROM coupons_log 
                          WHERE user_id=? AND coupon_id=?", 
                          [current_user.id, coupon_id])
   if received >= 1:
   return error("已达领取上限")
   

2. 安全增强措施

• 实施请求参数签名（HMAC-SHA256）
• 关键业务增加人机验证（Captcha/滑块验证）
• 对高价值券领取增加二次确认流程

-- 建立异常领取监控规则
SELECT user_id, COUNT(*) 
FROM coupon_log 
WHERE coupon_id IN (131,xxx) 
GROUPBY user_id 
HAVINGCOUNT(*) > 3-- 触发告警阈值

• 暂停受影响活动
• 审计异常领取记录
• 重置被滥用的优惠券状态