一、序言
在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限流。