昨天突然收到簡訊服務提供商報警，說我們的簡訊介面遭受攻擊，收到大量簡訊驗證碼通知。登入後臺管理服務，發現確實收到攻擊，正常一天的傳送量不會超過100條，但昨天已經突破三千，並且還在上漲；登入伺服器日誌檢視，也確實發現超出正常範圍的訪問請求。         當時寫介面的時候，用post請求，也就是想盡量不向攻擊者暴露介面引數，但還是想得太簡單了，攻擊者均為職業選手，或稱為黑客（雖然其實很低階），簡單的post或get無法迷惑他們。當初設計介面的時候，http請求，僅包含手機號碼在內的三個引數，伺服器沒有時間防護、簽名校驗等措施，基本屬於“裸奔”狀態，給“黑客”留下了漏洞。          修復此漏洞的方法，整理下來，不外乎以下五種：

1. 圖文驗證碼：在傳送驗證碼前，必須先進行圖文識別，通過後才可傳送驗證碼；除了有相當高的圖文驗證碼識別技術，一般圖文驗證碼是不容易被識別的，因此也是最有效的防攻擊手段；
   
2. 流程改進：在傳送驗證碼前，進行其他認證操作，比如密碼設定、身份識別、輸入更多資訊等，使得虛假資訊無法正常傳送。
3. 介面簽名：設定隱含的簽名金鑰，對介面請求引數進行簽名，在伺服器端進行簽名有效性的驗證。這種辦法也是一種較為有效的方法，但金鑰在客戶端的安全需要得到保證。
   
4. 時間防護：限制手機號碼在指定時間的傳送次數，比如60s或120s內僅允許一次傳送、一天僅允許10次傳送等，防止頻繁傳送；這種方式無法徹底解決簡訊攻擊問題。
5. ip防護：對發起傳送請求的伺服器ip進行限制。一般黑客發起攻擊的伺服器較為有限，當大批量的請求部署在伺服器上時，後臺會跟蹤到頻繁傳送請求的黑客伺服器ip地址，可以對其地址進行類似黑名單的管制。當發現同一個ip短期傳送大量請求時，可以限制其訪問。這種方式也無法徹底解決簡訊攻擊問題。

        從效果上說，圖文驗證碼最為可靠，其次改進流程，再次是介面簽名，時間防護和ip防護有其侷限性，但前三種均需要升級App客戶端，並且在App上進行圖文驗證、改進流程都影響使用者體驗，後面兩種可以直接在伺服器端生效，因此本次方案我選擇時間防護和ip防護。雖然無法徹底解決問題，甚至還會導致誤殺問題，但對於我們的現狀，還是可以起到顯著作用。通過對日誌和簡訊後臺的分析，綜合運用這兩種方案，明顯遏制了簡訊攻擊問題。         最後，我想，程式設計師不能偷懶，不能僥倖，“黑客”無處不在。