砍價活動風控的跟蹤記錄

前段時間，突遇滑鐵盧的砍價活動可以讓我頭髮禿了一大把。

砍價活動的業務線很簡單，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，趁着還有點時間，拾起以前的第三方風控，作滑塊校驗

 

但通過對接後發現該風控的滑塊校驗不支持微信小程序。。。黔驢技窮， 因爲運營計劃的時間成本等緣由，也來不及接入其餘第三方風控了。

因而活動暫停，風控以失敗了結。。。

結語：雖然結果難以接受，但也收穫了不少，見識了真正的黑產，正所謂道高一尺魔高一丈，以目前的團隊仍是有點捉襟見肘，慢慢提高本身吧。