zoukankan      html  css  js  c++  java
  • 拼多多优惠券bug造成千万损失引发的优惠券安全思考

    一. 背景

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

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

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

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

    img

    2.1 配置安全

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

    img

    2.2 预算管控

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

    img

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

    img

    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 发放条件校验失效

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

    img

    3.2 优惠券发放接入风控

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

    img

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

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

    img

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

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

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

    img

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

    3.5 水平鉴权漏洞

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

    3.6 并发风险

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

    3.7 篡改参数

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

    3.8 爬虫暴力攻击

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

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

    4.1 核销条件校验失效

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

    4.2 优惠券核销接入风控

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

    五. 监控及止损

    5.1 报警

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

    5.2 止损

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

  • 相关阅读:
    Oracle 按一行里某个字段里的值分割成多行进行展示
    Property or method "openPageOffice" is not defined on the instance but referenced during render. Make sure that this property is reactive, either in the data option, or for class-based components, by
    SpringBoot 项目启动 Failed to convert value of type 'java.lang.String' to required type 'cn.com.goldenwater.dcproj.dao.TacPageOfficePblmListDao';
    Maven 设置阿里镜像
    JS 日期格式化,留作参考
    JS 过滤数组里对象的某个属性
    原生JS实现简单富文本编辑器2
    Chrome控制台使用详解
    android权限(permission)大全
    不借助第三方网站四步实现手机网站转安卓APP
  • 原文地址:https://www.cnblogs.com/withwhom/p/11623329.html
Copyright © 2011-2022 走看看