一、序言 在Web開發中，總有一些介面需要暴露在用戶認證前訪問，簡訊發送介面特別是簡訊驗證碼註冊介面便是其中典型的一類，這類介面具有如下特點： 流量在用戶認證之前 流量在用戶認證之前，意味著無法獲取用戶ID等唯一標識符信息對流量限流 手機號未知 手機號未知意味著無法對待發送簡訊的手機號做精準檢測，判 ...
一、序言
在Web開發中，總有一些介面需要暴露在用戶認證前訪問，簡訊發送介面特別是簡訊驗證碼註冊介面便是其中典型的一類，這類介面具有如下特點：
- 流量在用戶認證之前
流量在用戶認證之前，意味著無法獲取用戶ID等唯一標識符信息對流量限流
- 手機號未知
手機號未知意味著無法對待發送簡訊的手機號做精準檢測，判斷是否是合法的手機號。通過正則表達式判斷手機號連號過多，容易滋生簡訊盜刷。
本文將重點聚焦介面的防盜刷實踐。
二、盜刷流量
在解決防盜刷之前先認識盜刷流量的特點和防盜刷的目標。
（一）防盜刷的目標
1、減少盜刷的總量
如果能將盜刷的頻率控制在60秒之外，那麼單日盜刷的最大數量為24*60=1440。假如系統入侵者發現請求頻率間隔在60秒以上，那麼可自動勸退入侵者，原因是投入與產出不匹配。
實際上盜刷流量以秒級甚至毫秒級刷新，對系統造成明顯的損害。
2、迴避周期性盜刷
周期性盜刷隱匿性更高，對系統有持續破壞能力，積少成多，不易察覺，相比於單次爆破性盜刷，周期性盜刷的危害可能會更大。
對於重要的介面，可考慮動態URL或者給參數增加時間戳簽名，避免靜態介面被暴露出去。
3、減小對正常用戶的影響
防盜刷的重要目標是避免因提高安全等級而誤傷正常用戶，即使對正常用戶有影響，也要減少相應的比率。
（二）盜刷流量的特點
盜刷與正常用戶流量有明顯區別，儘管盜刷可以模擬正常用戶，但是還是通用性區別。
正常用戶訪問是隨機的，失敗重試的次數有限並且也是隨機的。盜刷流量是周期性的，並且間隔很小。
正常用戶是通過瀏覽器或者APP間接的產生請求流量，盜刷通過代碼直接發送HTTP請求。
三、可行性方案
下麵通過逐步探究的方式，尋找合適的防盜刷方案。
（一）無安全防護
如果說重要的介面無安全防護措施，那麼過於粗心大意。僅靠簡訊運營商提供的限流和預警方案不能滿足簡訊防盜刷的需求，本質原因是手機號可以合法的模擬，簡訊運營商不管是正常手機號、停機號、註銷號還是尚未投入使用手機號，均會響應發送簡訊的指令，哪怕是空號發送不成功也會計數。實際上盜刷使用的空號正是介面盜刷的典型特征。
僅靠簡訊運營商提供的限流和預警方案不能滿足簡訊防盜刷的需求，儘管可以針對單個手機號定製發送簡訊限額，按小時、按天可定製發送總額，依然不滿足簡訊防盜刷的目標。當觸發限流時，正常用戶流量同樣被限流，對於簡訊註冊來說新增正常用戶受影響。如果惡意破壞者連多日耗盡限額簡訊資源，對正常用戶的使用影響很大。
（二）圖片驗證碼
在無防護措施的基礎上增加圖片驗證碼，有驗證碼的保護，簡訊介面相對安全許多。
簡訊驗證碼儘管能夠有效保護簡訊介面防盜刷，但是不能夠保護自己被盜刷。盜刷流量惡意刷新圖片驗證碼介面，給伺服器CPU造成極大的負載：圖片驗證碼服務與業務耦合，則業務可能響應緩慢；圖片驗證碼服務獨立部署，隔離了對業務的影響，但是圖片驗證碼伺服器CPU依舊可能過載，正常用戶依然收到影響。
Web系統使用圖片驗證碼正逐漸減少，原因是引入了圖片驗證碼保護了簡訊介面，卻無法保護自己。
（三）基於IP限流
上述兩種方法存在明顯的缺陷，實施落地時幾乎不使用，通過基於IP限流對無安全防護方案進行升級改造。基於IP地址，每60秒允許發送一條簡訊（不關聯手機號），通過後端強制限流，能夠大幅減少簡訊介面被盜刷的數量。
基於IP限流迴避了盜刷模擬手機號的影響，使用IP地址一刀切，穩妥的保證了簡訊介面的安全。
IP限流有個潛在隱患是如果惡意攻擊者與正常用戶復用同一個公網IP出口，那麼正常用戶可能會收到影響，不過這種情況影響範圍有限且可控。
惡意盜刷通過代理IP地址仍然能夠破解IP限流，只不過增加了破壞者的成本。
UCode CMS內置分散式IP限流的實現，可快速集成到項目中，請訪問開源項目中說明文檔獲取更多內容。
（四）動態請求
通過上述三種方案並沒有找到令人滿意的防盜刷方案，下麵在IP限流的基礎上繼續打補丁，升級到動態請求。
動態請求的核心思想是將簡訊驗證碼介面動態化，既可以介面URL動態化，也可以是參數動態化。下麵介紹一種基於時間戳簽名參數的方式，實現動態請求。
1、簽名參數生成
前後端約定簽名參數生成演算法，此演算法應當保密。
比如：手機號=18612345678，則key=MD5(手機號 + 當前時間/分鐘），這裡使用60秒的緩衝時間，也可以約定3分鐘或者5分鐘。
前後端都用這種方式生成key，前端頁面通過js腳本生成“簽名”，服務端“驗簽”。
需要註意的是：時間校驗要留buffer，客戶機時間與伺服器時間並不完全相同。
同一個簽名參數超過緩衝時間在後端無法實現驗簽，因此盜刷在不知道簽名演算法的前提下，盜刷流量有時間維度限制，解決了周期性盜刷的問題。
2、簽名演算法安全性
簽名演算法在後端是安全的，出開發人員外，幾乎無泄漏的可能。下麵著重討論簽名演算法在前端的安全性，以Web端和APP端討論。
（1）Web端
Web端通過JS實現簽名演算法，由於可通過瀏覽器直接查看JS，有泄露演算法的可能。不過目前大多數JS都是通過壓縮處理的，無法直接查看JS的詳細內容，如果前端做一些偽裝，破壞者找到簽名演算法有一定難度。
（2）APP端
相比於Web端，APP端的安全性略高，簽名拳法封裝在APP應用程式中，除非通過反編譯手段，無法得知簽名演算法的詳情。
對於非HTTPS流量，可通過抓包程式獲取簡訊介面的URL和參數，在不知道簽名演算法的前提下，仍不能周期性的盜刷。
四、小結
上述可行性方案逐步升級，能夠實現重要介面的防盜刷需求。
（一）防盜刷建議
對於重要介面的防盜刷，除了使用上述方案外，建議遵循如下要點：
1、使用POST請求
儘量使用POST請求方式，增加盜刷者的嘗試成本。
2、使用HTTPS
HTTPS在Web端形同虛設，在APP端有較為很好的保護作用，盜刷者通過抓包工具無法直接獲取介面的詳情信息，有效的保護了介面。
3、周期性修改介面
隨著項目的迭代升級，周期性的隨機變更重點介面的請求地址，前後端同步更新。
（二）補充說明
上述可行性討論方案適用於與簡訊註冊類似的介面。
1、簡訊登錄介面
簡訊登錄在IP限流的基礎上增加手機號BitMap檢驗，如果當前客戶端訪問IP限流正常，並且當前請求手機號已經註冊，則發送簡訊。
簡訊登錄介面無必要使用複雜的動態請求的方式，原因是已經預設了當前請求手機號存在資料庫中，如果不存在那麼便是錯誤請求，快速響應即可。
UCode CMS內置分散式BitMap的實現，可快速集成到項目中，請訪問開源項目中說明文檔獲取更多內容。
2、已認證介面
對於已經經過登錄認證的介面，可使用用戶ID限流，直接在無安全防護的基礎上使用用戶ID限流。
喜歡本文就【♥️推薦♥️】一下，激勵我持續創作。這個Github同樣精彩，收到您的star我會很激動。本文歸檔在專題博客，視頻講解在B站。
