一. 背景

“ 今日凌晨，拼多多爆出可领无门槛100元优惠，引得广大网友竞相争抢，据说短短时间出现300亿交易额，其中200亿是虚拟产品，这200亿可能就是拼多多损失的数额。目前，拼多多回应，已把领到的优惠券回收，并修复BUG。据悉拼多多方面因为此损失数千万，目前已报案。” －－摘自搜狐新闻 2019.1.20

抛开拼多多是否自导自演，该事件引发了我对优惠券安全性的重新思考和整理。优惠券具有生命周期长，涉及环节多，玩法灵活等特点，这就决定了优惠券安全和所有涉及的各方（券配置方，发券配置方，风控，运营等）都息息相关，任何一方存在风险都会影响优惠券的安全性。

二. 配置平台涉及优惠券安全常见场景

一张优惠券从创建到消亡是有生命周期的（这里只描述在配置后台的生命周期，暂不涉及发布上线后到用户手中的部分），如下图所示：

2.1 配置安全

创建一张优惠券，主要包含三大类配置项：基本属性，核销条件，发放条件，如果配置优惠券平台缺少必要配置项，或配置项区分度不够，将使优惠券发放和核销不可控，因此优惠券配置平台应具有配置发放和核销可精细化控制的能力。

2.2 预算管控

平台优惠券（由平台承担费用的抵用券）的预算由预算系统进行管控，预算管控可分为两大类，即强管控和弱管控，强管控即为不允许花超，弱管控即为允许花超，但超太多应设置警告。预算系统与优惠券系统在三个交互时机，如图所示：

预算系统维护各组织部门的预算，一个预算号表示一笔可用的预算，优惠券在创建过程中需要填写将占用预算的预算号，因此预算系统需要保证预算不被非法消耗，保证预算安全，一种预算号权限控制方式如下：

c1可以使用预算组织A,B和C1的预算，但不能使用预算组织C2的预算；而a可以使用预算组织A,B,C1,C2的预算，预算组织的节点越大，就越多人能使用；或者预算组织C2的预算流水号s授权给c1，c1也可以使用预算号s，同时离线优惠券数据需考虑进行数据脱敏，降低活动预算被他人非法消耗的风险。

2.3 风控审批

优惠券的创建与修改需经过风控审批，如果优惠券的创建划分为多个阶段，比如分为创建优惠券（配置基本属性与用券条件），再创建发优惠券活动（配置发券条件），则每个阶段的创建和修改都应经过风控审批。例如运营创建一张满0元减10元且不受领取数量限制的老客可用优惠券，如果优惠券配置平台对创建与修改有风控审批环节，这种高风险优惠券将在风控审批过程被拦截，因此优惠券配置平台应具有创建与修改优惠券时风控可感知，可控制的能力。

2.4 权限控制

只能查看与修改自己创建的优惠券，只能查看与修改自己创建的发优惠券活动，且发优惠券活动只能关联自己创建的优惠券。

2.5 操作记录

优惠券配置、修改、风控审批、发布各环节操作记录。

三. 优惠券发放服务安全设计

3.1 发放条件校验失效

因各种原因导致优惠券发放条件校验失效，例如优惠券发放条件中设置了发放渠道限制，但上游未传发放渠道信息，代码设计为不传即不校验，导致出现发放渠道限制失效的风险。因此对优惠券发放条件应进行强校验。

3.2 优惠券发放接入风控

虽然有用户领取限制，但黄牛可能注册多个用户对优惠券进行领取，风控可根据用户属性、设备属性等进行判断，防止盗刷优惠券。

3.3 优惠券平台发券标识被遍历

发券方直接使用优惠券id作为发券标识时，如果id值域过小且自增，并且券id直接明文暴露在发券接口中，会被黄牛掌握规律遍历所有的券。

解决方案：对内部券id进行加密10001 -> U2FsdGVkX19rKRB1RNmH6h/xoFk10cf13njDmtRUVcE=

3.4 优惠券平台上游发券服务的发券标识被遍历

发券平台上游服务直接使用优惠券id作为发券标识时，如果id值域过小且自增，并且券id直接明文暴露在发券接口中，会被黄牛掌握规律遍历所有的券。

解决方案：上游服务接入券平台时，券平台应沟通发券方案，确保上游服务没有被遍历的风险。

3.5 水平鉴权漏洞

优惠券平台通常服务于多个发券渠道，每个优惠券或者优惠券发放活动都有发放渠道归属，每个优惠券应仅允许归属的发放渠道发放。

3.6 并发风险

使用分布式锁解决并发导致的各维度库存失效（发券总量限制，日发券总量限制，用户发放总量限制，用户单日发放总量限制等）

3.7 篡改参数

如对外提供http服务，可能存在被篡改前端参数的风险，需要进行验签。这里可根据需要选择不可逆加密算法或者可逆加密算法（对称加密或非对称加密）。

3.8 爬虫暴力攻击

爬虫暴力攻击导致业务服务器压力过大，影响正常服务，需要接入发爬服务，关于爬虫于反爬虫的斗争网上资料很多，况且我也只是了解一些，没有深入研究，这里就不详细分析了。

四. 优惠券核销服务安全设计

4.1 核销条件校验失效

因各种原因导致优惠券核销条件校验失效，例如优惠券核销条件中设置了用户限制，但代码设计问题导致绕过用户属性校验，导致出现核销用户限制失效的风险。因此对优惠券核销条件应进行强校验。

4.2 优惠券核销接入风控

虽然有多维度的用户核销库存限制，但黄牛可能注册多个用户对优惠券进行核销，风控可根据用户属性、设备属性等进行判断，保障核销券的用户都是自然人。

五. 监控及止损

5.1 报警

设置基本的发放金额阈值、核销金额阈值、发放条件失效可感知、核销条件失效可感知及关键代码块异常或者指标报警。

5.2 止损

在代码设计中需要考虑的非常重要的一个问题是：上线如果出问题怎么办？抵用券系统故障会涉及资损，因此需要有及时止损的能力，可一健降级。

转载于:https://www.cnblogs.com/withwhom/p/11623329.html