砍價活動風控的跟蹤記錄
2021-02-27 21:47
第二個卿老師
閱讀(205)
評論(0)
編輯
收藏
舉報
前段時間，突遇滑鐵盧的砍價活動可讓我頭發秃了一大把。
砍價活動的業務線很簡單，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，趁着還有點時間，拾起之前的第三方風控，做滑塊校驗
但經過對接後發現該風控的滑塊校驗不支援微信小程式。。。黔驢技窮，由于營運計劃的時間成本等原因，也來不及接入其他第三方風控了。
于是活動暫停，風控以失敗告終。。。
結語：雖然結果難以接受，但也收獲了很多，見識了真正的黑産，正所謂道高一尺魔高一丈，以目前的團隊還是有點捉襟見肘，慢慢提升自己吧。
- 分類 測試技術