【驗證碼機制原理】

客戶端發起請求->服務端響應并創建一個新的SessionID同時生成隨機驗證碼，將驗證碼和SessionID一并返回給客戶端->客戶端提交驗證碼連同SessionID給服務端->服務端驗證驗證碼同時銷毀當前會話，返回給客戶端結果。

【客戶端可能存在的安全問題】

1、有的網站驗證碼由本地js生成僅僅在本地用js驗證。可以在本地禁用js，用burp把驗證字段刪除。
2、有的網站把驗證碼輸出到客戶端html中，送到客戶端Cookie或response headers。
3、有些網站默認不顯示驗證碼，而是在輸入錯誤一定數量之后才需要驗證驗證碼，開發人員可能在Cookie中寫入一個標記loginErr，用來記錄錯誤數量，則可以不更新Cookie中的loginErr值反復提交，驗證碼就不會出現。

【服務端可能存在的安全問題】

1、驗證碼不過期，沒有及時銷毀會話導致同一驗證碼反復可用。攻擊者可以在Cookie中帶固定的sessionID和固定的驗證碼字符串。
2、沒有對驗證碼進行非空判斷，導致可以直接刪除驗證碼參數。
3、產生的驗證碼問題有限

驗證碼固定

導致驗證碼不刷新（固定）的原因是：登錄密碼錯誤之后，session中的值沒有更新，驗證碼不變。驗證碼不刷新通常有以下兩種情況：無條件不刷新、有條件不刷新。

無條件不刷新

無條件不刷新是指在某一時間段內，無論登錄失敗多少次，只要不刷新頁面，就可以無限次的使用同一個驗證碼來對一個或多個用戶帳號進行暴力猜解。換句話說，攻擊者可以在同一個會話下，在獲得第一個驗證碼后，后面不再主動觸發驗證碼生成頁面，并且一直使用第一個驗證碼就可循環進行后面的表單操作，從而繞過了驗證碼的屏障作用，對登錄進行暴力猜解。

【測試案例 1】測試人員登錄并抓取請求包，在不改變驗證碼的情況下，多次發送請求包，響應包中內容都是“用戶名或密碼錯誤”，如下圖所示：
【安全建議】建議針對一次請求生成的驗證碼只能用一次，用完立即過期。每次生成的驗證碼不允許跨會話和請求使用。

有條件不刷新

有條件不刷新多見于如下情況：登錄失敗之后，系統會打開一個新頁面或者彈出一個新的警告窗口，提示用戶登錄失敗，點擊確定后返回登錄界面且驗證碼刷新。這種情況下，只要我們不關閉新窗口或彈窗，配合使用Burpsuite的intruder模塊就可以進行暴力破解了。

【測試案例 2】來看下某系統的驗證碼鑒權流程：

用戶輸入賬戶信息+驗證碼(刷新頁面或手動刷新驗證碼會從服務器獲取驗證碼，但該驗證碼緩存于session中)，服務端接收到賬戶信息+驗證后會先校驗驗證碼是否正確，若不正確則，返回反之與數據庫做對比，符合則返回，客戶端接收服務端的請求，若成功則跳轉，返回根據不同的錯誤碼提示相應信息，并重新獲取服務端生成的新驗證碼，重新緩存。

【問題描述】看完流程可以很容易想到一個問題：驗證碼此時并不會重置，一切重置驗證碼的操作都在瀏覽器，所以在Session不失效的時效內，可以無限重用驗證碼，這時就可以使用BurpSuite進行暴力破解了，驗證碼形同虛設。

驗證碼前端可獲取

這種情況在早期的一些網站中比較常見，主要是因為程序員在寫代碼的時候安全意識不足導致的。驗證碼通常會被他們隱藏在網站的源碼中或者高級一點的隱藏在請求的Cookie中，但這兩種情況都可以被攻擊者輕松繞過。

驗證碼隱藏在源碼之中

驗證這種情況很簡單，我們只需要記住驗證碼，然后右鍵打開網站源代碼，Ctrl+F搜索，輸入剛才的驗證碼，如果可以成功匹配到，那恭喜你，接下來就可以寫工具，提取源碼中的驗證碼并將其放入每次請求的報文中，來進行帳號破解，這里推薦使用python。

驗證碼隱藏在Cookie中

一般來說，我們會把驗證碼的值用Session存儲起來，通過對比用戶提交的驗證碼和Session中的驗證碼，就可以知道輸入是否正確。由于Session會占用服務器資源，有的開發人員會把驗證碼的值加密后存儲在Cookie中。

這種情況，我們可以在提交登錄的時候抓包，然后分析一下包中的Cookie字段，看看其中有沒有相匹配的驗證碼，或者是經過了一些簡單加密后的驗證碼。

僅在客戶端生成驗證碼

有的網站驗證碼由本地js生成僅僅在本地用js驗證。

【實際案例】

測試人員抓取登錄過程的請求包，如下圖所示：

從上面抓取到的數據包可以看出，雖然該系統存在驗證碼，但是其驗證碼并沒有向服務器傳輸，而是在本地客戶端直接進行驗證。我們可以在輸入一次正確的驗證碼（繞過客戶端驗證）后，使用BurpSuite對用戶名和密碼同時進行暴力猜測，如下圖所示：

返回的數據是“賬號不存在”，而不是“驗證碼錯誤”，說明此處已不需要輸入正確的驗證碼就能發送登錄請求，只要密碼字典夠大，我們就能進行暴力破解。

計算類型的驗證碼，如1+8=？，這種類型的驗證碼嚴格意義上來說不能叫做驗證碼，多刷新幾次驗證碼，我們可能會發現系統中的算數題目只有那么幾道，這種情況下只要將驗證碼全部下載下來，生成一個md5庫，然后將前端生成的驗證碼與本地文件進行對比即可。

驗證碼薄弱

驗證碼自動識別

有的系統雖然在登錄界面帶了驗證碼，但是驗證碼功能薄弱，可以被工具識別，導致系統面臨被爆破登錄的風險。
點擊F12打開開發者工具，查看前端源碼，找到生成驗證碼的URL。
將URL輸入搜索框，驗證是否正確。

然后，打開工具PKAV HTTP FUzzer，開始嘗試自動識別驗證碼。


建議對驗證碼進行干擾、變形處理！

驗證碼爆破登錄

緊接上面的系統案例，接下來同樣借助工具PKAV HTTP FUzzer，咱們進行帶驗證碼登錄頁面的暴力破解。

（1）首先，使用Burp Suite抓包

（2）把數據包丟進PKAV工具，分別標記password、驗證碼（username事前知道了，即存在admin的用戶，無需用字典猜測，故此處不用標記）。

（3）給標記的變量添加猜測字典。字典可選工具自帶的，也可用專門的字典生成工具生成。

或者使用工具生成字典：

（4）添加驗證碼地址

在登錄框找到驗證碼地址復制到工具，識別范圍看情況，這里為數字+字母。

（5）設置參數

切換到重換選項卡設置相關參數，具體設置看情況而定。

（6）識別驗證碼測試

相關參數設置好之后，點擊進行識別測試。

（7）開始爆破

接下來，耐心等待爆破結果。

總結

以上是生活随笔為你收集整理的渗透测试-验证码的爆破与绕过的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。