pikachu~~~驗證碼繞過（on client & on server）

index

• 基于服務端的驗證碼繞過（On service）
• 基于用戶端的驗證碼繞過（On client）
• 【用戶端可能存在的安全問題】
• 【服務端可能存在的安全問題】

我們要來思考一下，什麼是驗證碼繞過？

首先，我們在哪裡會經常使用到驗證碼？

對咯，在各web網頁以及APP的登陸界面，會讓我們輸入：使用者名，密碼，驗證碼這三項。

那繞過？怎麼繞過呢？

那比如說，你在軟體園，去B8上課，走着走着，哎？這個平時走的路被圍上了，在修路，這兒走不了了，你一定要直着走過去嗎？那修路的大爺估計就要抽你了。

那你咋辦？你一看旁邊牌子，此路不通，請繞道而行。那你可以通過一些途徑繞過去嘛，是吧。那驗證碼也是一樣的，你同樣可以把他繞過去。

既想繞過去他，我們必須要了解一下他的原理，上圖。

我們今天着重研究基于用戶端和服務端的驗證碼繞過，實踐出真知，讓我們開啟實驗之旅！

基于服務端的驗證碼繞過（On service）

驗證碼錯誤時會報錯，但不會過期，session有效期間vcode仍然有效。

思路：

判斷驗證碼在輸入錯誤時是否顯示

判斷驗證碼是否有非空錯誤

判斷驗證碼重新整理後是否還能重複利用

輸入資訊後先抓包

發送到repeater後修改驗證碼，修改驗證碼後顯示：

删除驗證碼後顯示：

接下來測試驗證碼是否能重複利用：

重新整理頁面後重新擷取一個驗證碼，

Repeater不修改驗證碼，再回去驗證，顯示驗證碼錯誤

輸入目前正确的驗證碼多次發送，顯示success,說明驗證碼存在不過期，可以重複利用。

是以開始暴力破解

由于響應資料的不确定因素，中文在加載字典的時候是亂碼，這裡為了顯示好看，隻比對英文部分，可以使用正則：“LoginId”:"([a-zA-Z0-9_]+)",“NickName”，最終提取的都是英文字元。

基于用戶端的驗證碼繞過（On client）

紙老虎，驗證碼随意修改不報錯，由前端生成且隻在前端處理。

思路：

檢視源碼JS有無問題

判斷驗證碼錯誤和為空時情況

先看JS，右鍵檢視網頁源代碼

<label><input type="text" onclick="createCode()" readonly="readonly" id="checkCode" class="unchanged" style="width: 100px" /></label><br />                <label><input class="submit"  name="submit" type="submit" value="Login" /></label>
onclick="createCode()"調用JS生成驗證碼
           

檢視源碼，我們發現驗證碼的生成是在前端中實作的。

驗證碼錯誤時，依然顯示成功。

驗證碼并沒有什麼作用，設定暴力破解方式

在前端中用js來做驗證碼是不安全的，很容易被繞過。

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

1、有的網站驗證碼由本地js生成僅僅在本地用js驗證。可以在本地禁用js，用burp把驗證字段删除。

2、有的網站把驗證碼輸出到用戶端html中，送到用戶端Cookie或response headers。

3、有些網站預設不顯示驗證碼，而是在輸入錯誤一定數量之後才需要驗證驗證碼，開發人員可能在Cookie中寫入一個标記loginErr，用來記錄錯誤數量，則可以不更新Cookie中的loginErr值反複送出，驗證碼就不會出現。

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

1、驗證碼不過期，沒有及時銷毀會話導緻同一驗證碼反複可用。攻擊者可以在Cookie中帶固定的sessionID和固定的驗證碼字元串。

2、沒有對驗證碼進行非空判斷，導緻可以直接删除驗證碼參數。

3、産生的驗證碼問題有限

Sniper（狙擊手模式）：一次隻會對一個位置進行攻擊

Battering ram（攻城錘模式）：同樣情況下，攻擊次數減半，每次兩個位置用同樣的密碼

Pitchfork（叉子模式）：可以多組密碼本payload，每個都不同

Cluster bomb（炸彈模式）：交叉組合，每一個密碼本裡的密碼都對應于另一密碼本所有密碼