昨天突然收到簡訊服務提供商報警，說我們的簡訊介面遭受攻擊，收到大量簡訊驗證碼通知。登入後台管理服務，發現確實收到攻擊，正常一天的傳送量不會超過100條，但昨天已經突破三千，並且還在**；登入伺服器日誌檢視，也確實發現超出正常範圍的訪問請求。
當時寫介面的時候，用post請求，也就是想盡量不向攻擊者暴露介面引數，但還是想得太簡單了，攻擊者均為職業選手，或稱為黑客（雖然其實很低階），簡單的post或get無法迷惑他們。當初設計介面的時候，http請求，僅包含手機號碼在內的三個引數，伺服器沒有時間防護、簽名校驗等措施，基本屬於「裸奔」狀態，給「黑客」留下了漏洞。
**驗證碼：在傳送驗證碼前，必須先進行**識別，通過後才可傳送驗證碼；除了有相當高的**驗證碼識別技術，一般**驗證碼是不容易被識別的，因此也是最有效的防攻擊手段；
介面簽名：設定隱含的簽名金鑰，對介面請求引數進行簽名，在伺服器端進行簽名有效性的驗證。這種辦法也是一種較為有效的方法，但金鑰在客戶端的安全需要得到保證。
時間防護：限制手機號碼在指定時間的傳送次數，比如60s或120s內僅允許一次傳送、一天僅允許10次傳送等，防止頻繁傳送；這種方式無法徹底解決簡訊攻擊問題。
ip防護：對發起傳送請求的伺服器ip進行限制。一般黑客發起攻擊的伺服器較為有限，當大批量的請求部署在伺服器上時，後台會跟蹤到頻繁傳送請求的黑客伺服器ip位址，可以對其位址進行類似黑名單的管制。當發現同乙個ip短期傳送大量請求時，可以限制其訪問。這種方式也無法徹底解決簡訊攻擊問題。
最後，我想，程式設計師不能偷懶，不能僥倖，「黑客」無處不在。
簡訊驗證碼
簡訊驗證碼 圍繞以下兩個方法開展 1 sendcaptcha 獲取驗證碼 2 commitcaptcha 提交驗證碼 方法 1 addtextchangedlistener 文字變化 2 requestfocus 請求焦點 3 string phone etphonenum.gettext tost...
簡訊驗證碼
你的key access key secret 你自己的key 注意 不要更改 region cn hangzhou product name dysmsapi domain dysmsapi.aliyuncs.com acs client acsclient access key id,acces...
Android之簡訊驗證碼
我們今天所使用的方案只是android手機裝置整合簡訊驗證碼功能的方案之一。我們所採用的方案是使用聚合資料的簡訊驗證sdk。程式的介面如下所示 實現步驟 5.完成主demo類，內容如下 import android.content.pm.activityinfo import android.os....