驗證碼的應用場景有很多，但相對較多的是用在登入頁面、支付頁面或敏感資訊修改的地方需要輸入，有的時候登入頁面雖然設定了驗證碼機制，但是很有可能存在驗證碼可被繞過的情況，如此一來可能帶來使用者密碼暴力破解或窮舉應用系統的使用者名稱資訊等風險。下面分析一下驗證碼可能被繞過的幾種情況。
（1）登入頁面壓根就沒有驗證碼機制，這沒什麼好說的，去完善驗證碼機制吧。
（2）登入頁面驗證碼雖然設定了，但是抓包後刪除驗證碼欄位名及字段值仍可以傳送到伺服器，而且伺服器還可以正常的返回response，並且可以多次重**送，這種情況就是服務端完全沒有校驗，這種錯誤比較low但是還真的有發現過。
（4）驗證碼設定了，篡改伺服器返回的response後也報錯了，並且也沒給你篡改類似errorcode的地方和機會，這種情況下是不是就沒有辦法了。其實還有一種情況，就是探測應用系統是否有使用者在使用弱口令的這個問題。比如說乙個登入頁面，需要使用者輸入使用者名稱、密碼和驗證碼。開發者在設計程式的時候給出了乙個驗證碼只能使用一次的標準，並且後台校驗如果嘗試登入失敗次數大於5次的時候就鎖定使用者登入。聽起來可能已經做得很網際網路很安全了。但是，如果把登入的request抓包下來，發現使用者名稱只是以簡單的6位數字進行標示的話，那麼使用者名稱的數量無非就是000001~999999個而已，注意，這個時候如果驗證碼沒有做到每用一次就報廢的話，那麼在a賬戶錯誤5次前（被鎖定前），使用相同的弱口令+相同的驗證碼再次切換到其他使用者下以嘗試是否可登入，這種方式其實是可以探測到使用者是不是有在
使用弱口令的。
比如以下的請求方式：每個賬戶號嘗試的次數都沒有超過5次，所以每次都不會被鎖定。嘗試傳送的弱口令選取概率相對較高的12345678、11111111、66666666、88888888，然後驗證碼雖然在頁面上只能用一次，但是抓包後卻可以反**送同乙個請求。這樣就達到了探測是否有使用者在是使用弱口令的情況了。
賬戶號 + 賬戶密碼 +驗證碼
000001+12345678+2367
000001+11111111+2367
000001+66666666+2367
000001+88888888+2367
000002+12345678+2367
000002+11111111+2367
000002+66666666+2367
000002+88888888+2367
000003+12345678+2367
000003+11111111+2367
000003+66666666+2367
000003+88888888+2367
...999999+12345678+2367
999999+11111111+2367
999999+66666666+2367
999999+88888888+2367
可能有人會覺得這種情況的攻擊成本很高，但請記住如果攻擊者有足夠多的時間和耐心加上足夠好的運氣的話，還是可以嘗試破解出來的，所以如果發現了這個問題的話最好還是修復一下吧。
附上一些見到的比較個性的驗證碼校驗機制，逐漸新增中
小記 驗證碼操作
首先需要匯入工具包，直接在mvn倉庫搜尋 注意是這個頭像，不要引錯了，有幾個名字重複的 驗證碼配置類，spring啟動就會將配置類載入spring容器當中 configuration public class kaptchaconfig 當然，kaptcha中有很多配置，詳細配置如下 kaptcha...
驗證碼安全
目錄後端未對單次驗證碼的有效時間和有效次數限制 或者驗證碼僅在前端校驗，後端不校驗 導致單次驗證碼可多次使用 造成賬號密碼可被列舉 影響驗證碼大小的引數前端可控，如引數在url中 導致可修改引數並利用burp批量發包 造成ddos消耗伺服器資源 後端未對動態驗證碼如簡訊驗證碼的有效域或歸屬做嚴格限定...
驗證碼 簡單驗證碼識別
這裡的驗證碼是內容非常簡單的，結構非常清晰的 這裡的驗證碼是內容非常簡單的，結構非常清晰的 這裡的驗證碼是內容非常簡單的，結構非常清晰的 興之所至之所以說簡單，我覺得是這樣的 抽了五張驗證碼扔進ps，50 透明度，長這樣 只有數字為內容 每張圖的數字都在固定位置 沒有太大的干擾因素 數字字型，形態完...