砍价活动风控的跟踪记录

前段时间，突遇滑铁卢的砍价活动可以让我头发秃了一大把。

砍价活动的业务线很简单，APP或小程序参与而后直接邀请微信好友助力，被助力成功后就能够领取限量奖品，先到先得，而帐号是跟手机号绑定的。

整体看来功能也不算复杂，再到上线后的跟踪，前几期活动都没啥大问题。

但我总以为有点太顺利了。。。

终于在开始第四期的活动时，发现一些数据很可疑。

1，线上监控日志发现不少异常调用接口的请求

2，存在部分新注册的用户头像同样，虽然手机号不同

3，砍价过程当中奖品库存数量减小得很快，一个奖品最快2-3分钟就砍完了（砍价主要是邀请新用户）。

4，活动接入的第三方风控没有预警

4，发现邀请的新用户助力时间分布间隔很是近

由于项目开发时就已经考虑了第三方风控，因此首先查看第三方风控的日志记录，发现风控后台的帐号（手机号）检测正常，这就有点矛盾了。。。

 第一期数据采集分析

由于正常流程是在小程序发起的，并且新用户助力须要在小程序登陆，因此能够记录到用户的unionId，结合线上被刷接口的日志。

分析后作了如下优化：

• 助力请求包含用户的unionId，后端保存该unionId
• 前端增长第三方的数据埋点

接着是测试后第五期活动上线，并实时跟踪线上活动效果，发现本来能持续3天活动奖品，当天就被抢完了，这库存减小速度明显着异常，看来是遇到羊毛党了。

好了，第五期活动一结束就拉着相关人员开会，也算是风控的真正开始。

第二期风控优化

经过会议讨论，初步发现：

1，数据库中约80%的助力记录中没有unionId，小程序最新版本正常助力会传unionId

2，因为微信小程序更新存在延迟，线上存在部分老版本，故没法回传unionId

3，部分运营反馈的风险用户，其中部分助力数据显示正常（没有重复的unionid、手机号、ip等）

4，其中第三方埋点统计的按钮点击次数也与总助力次数相差极大（考虑到用户可能屡次点击，正常状况下同一次砍价流程，埋点数>=助力次数）

5，第三方风控本次活动检测数为上期活动检测数的1/4，即大部分助力绕过了风控平台

6，因为活动助力仅能在小程序发起，即一定会绑定小程序，而unionId是用户绑定小程序的惟一凭证，因此unionId能够做为助力必传字段

因为第三方风控但是付费了的！先从这边入手。

发现当时为了提升性能，后端设计时，仅是在助力页面加载时作了风控效验，助力接口上没有效验。那么羊毛党获取到相关参数后，经过助力接口就能够绕过检测。

那么是否把风控效验放到助力接口上？

接着顺便找了几个帐号对风控作了准确性测试，发现羊毛党帐号中的所有助力用户仅能识别50%的用户为可信用度低，其余均为白名单用户，即返回数据存在误杀。

若是风控效验放到助力接口上，又不想误杀，第三方风控人员建议咱们接入滑块效验，因为接入滑块可能须要更改业务流程，影响性能的同时改动周期比较长（涉及购买合同等等），暂时不考虑。

分析后作了如下优化：

• 前端助力接口必传unionId参数，且后端验证unionId是否已存在，不存在则判断用户助力失效，重复unionId用户的助力机会取活动的助力次数上限。
• 助力用户的IP地址的风控限制，因为切实存在IP地址相同的场景，该值上限可作配置化。
• 前端优化助力操做的第三方埋点事件（助力成功后才会统计），包括小程序的版本号。
• 因为效果通常，先去掉第三方风控。

异常订单处理，后置风控！

对照第三方埋点数据，通知运营对异常订单不发货，进一步避免损失吧！

个人头发开始掉了。。。

接着是测试后第六期活动上线（奖品数量较少），并实时跟踪线上活动效果，发现初期活动奖品的库存减小速度正常，后期库存减小速度异常，半天后活动所有奖品砍完。

能够看出：初期因为风控使羊毛党用户没法正常砍价，然后期怀疑羊毛党伪造脚本升级致使异常，即上期风控存在效果但还须要持续优化！

第三期风控优化

经过会议讨论，初步发现：

1，用户小程序受权后不进行小程序登陆，经过调用app登陆接口，获取相关信息后也能进行砍价（漏洞）

2，并且运营在用户群里面发现了活动帮砍广告，进一步发现羊毛党开发了针对性的砍价工具，缴少量费用后就能帮砍成功（以下图，太嚣张了）

 

 3，后端监控日志发现登陆接口被刷，而登陆接口与线上活动接口不知什么时候关闭了验签功能（汗颜） 

 

针对1漏洞，用户小程序登陆的流程分为两步（小程序登陆的  官方参考连接 ）：

• 第一步是受权，其中受权后服务端就会保存该用户的unionId，只是此时不生成用户ID。
• 第二步是登陆，老用户受权后自动为登陆状态，若是是新用户登陆，以前受权的unionId就会与用户ID生成绑定关系。

因此非法调用APP登陆以获取到有效token，就能绕太小程序登陆，也能正常助力，但该状况不会生成绑定关系。

因而助力人的unionId与该用户ID存在绑定关系才能助力成功！

此外还准备了两个杀手锏，一是页面接口加入身份校验参数A，助力时入参须要把参数A带上；二是助力接口入参PB化（Protobuff），门槛瞬间提升几丈。

因而整理风控解决方案以下：

• 针对助力接口，后端须要验证该unionId是否与助力的用户ID是否匹配，匹配正常才能助力。
• 登陆接口与线上活动接口开启验签功能。
• 助力接口增长身份校验参数，并对接口入参进行PB化。
• 第三方埋点数据分析，用户砍价存在助力的埋点记录即为正常助力。
•   异经常使用户加入砍价黑名单，须要提供往期黑名单用户

继续异常订单处理！

和上次同样同步异常订单给运营，运营已经面露难色！

个人头发掉得更厉害了。。。

接着是测试后第七期活动上线（奖品数量多，但部分质量较低），并实时跟踪线上活动效果，发现活动共持续了3天，奖品的库存减小速度正常，到活动结束时仍然存在剩余奖品。

因为第三方数据平台会记录小程序端助力的埋点数据，补充分析以下：

1，活动完成后，统计第三方埋点数据与总的助力次数，发现99.4%的数据是正常的（埋点统计可能存在偏差）——证实风控有较好效果

2，统计砍价成功的助力数据，若是助力次数<埋点次数，则用户存在砍价异常（埋点统计可能存在偏差，5个之内能够接受）。

注：仅发现一个用户误差较大（占0.2%），已同步给运营，综合分析后发现该用户的各类砍价行为正常，可能须要再次观察 ——证实风控存在较小风险

能够看出：活动期间库存减小速度正常，短时间内使羊毛党用户没法正常砍价，整体来看此次风控是有效的（部分奖品价值较低，不排除羊毛党没参与本次砍价），因此下期活动能够放开点。

两天后第八期活动上线！

本期奖品数量多，但部分质量较低，原计划持续2天的活动仅持续了1天多点，结合反馈，第一天的凌晨后库存减小速度开始异常，用户助力时间分布间隔很是近。

。。。。。。so风控还须要再次优化！

第四期风控优化

经过会议讨论，初步发现：

1，本期活动全部助力成功用户记录有8万多条。

2，本期活动全部助力成功记录埋点有7万多条。

3，本期砍价成功的助力记录为7万多条，与神策次数对比，通过运营统计异常订单占33%。

4，存在非法用户购买了砍价工具，并发布了帮砍广告。

经过后台日志分析，发现小程序登陆接口调用正常？

 

上图为官方说明，咱们在前端受权后，服务端会把正确的sessionKey返回给前端（官方提示不能传），若是羊毛党知道正确的OpenId、UnionID及对应的sessionKey，是否是就能反向破解sessionKey了。。。

能不能破解已经不敢想了，必须立刻隐藏sessionKey！！！

为了兼容老版本，sessionKey作了映射，至关于返回一个假的sessionKey而且每次使用后就会删除映射关系。

经过会议讨论，考虑到成本、时间与后期规划，解决方案以下：

1，小程序登陆参数秘钥策略调整（sessionKey隐藏） 。

2，减小羊毛党砍价速度，同一个用户 新用户1分钟助力不得超过5次 。

3，人工实时预警，加入黑名单干预用户砍价。

4，购买并分析砍价工具，针对调整

又是异常订单处理！

和上次同样不太同样的是，运营开始主动索要异常订单了！

已经来不及关注头发了。。。

接着次日第九期活动上线，活动开始前两小时，库存减小正常，中午开始库存减小异常，原计划持续2天的奖品，半天多奖品所有砍完，so上期风控优化点基本无效。

第五期风控优化

 经过会议讨论，初步发现：

1，本期活动本期活动全部助力成功记录第三方埋点有9千多条，约一半的助力记录存在异常。

2，经过后台日志分析，发现小程序登陆接口调用正常，没有出现伪造的调用记录。

3，以前购买的砍价工具都是后台操做，前端根本看不出来啥，想到羊毛党这方面应该有措施，直接放弃

先处理异常订单吧！

有人投诉咱们了，运营说，能不能风控前置，避免异常订单！

头发一抓一大把。。。

要不考虑下跟第三方埋点平台打通？一条埋点数据对应一次成功助力！

首先第三方埋点是小程序客户端的按钮事件，非法用户首先得捕捉这个请求，其次得破解第三方埋点的通信加密，伪形成本那是至关的高，但反过来想一想。。。

咱们若是要打通第三方平台

• 须要第三方提供数据查询或支持数据回传的功能，第三方说均可以的，只不过要加钱。。。
• 埋点数据会有延迟，实时性不高，意味着可能会花费很长时间去判断一次助力是否正常！
• 埋点数据会有偏差，可能客户端产生4次事件，而第三方收集的数据可能只有3条，2条。
• 打通第三方平台可能须要产品程度上从新设计。。。

思来想去，彷佛这个工做量与费用不亚于一个新的第三方风控了，怎么办？

该作的都已经作了，并且调用记录都是正常的！！！

是否是微信登陆第一步受权已经被破解了，因此伪造的都是正常的数据？

网上一查，也有公司遇到过相同的问题，怀疑 wx.login() 获取的临时登陆凭证code能够被伪造，可是微信官方也没有给出回答。。。

有点泄气的咱们，经过会议讨论决定：

1，趁着还有点时间，拾起以前的第三方风控，作滑块校验

 

但通过对接后发现该风控的滑块校验不支持微信小程序。。。黔驴技穷， 因为运营计划的时间成本等缘由，也来不及接入其余第三方风控了。

因而活动暂停，风控以失败了结。。。

结语：虽然结果难以接受，但也收获了不少，见识了真正的黑产，正所谓道高一尺魔高一丈，以目前的团队仍是有点捉襟见肘，慢慢提高本身吧。