0x00 前言

其實drops裡面已經有小胖胖@小胖胖要減肥 和A牛@insight-labs 相應的文章，只是覺得應該有個入門級的“測試用例”。本文不涉及OCR，不涉及暴力四六位純數字驗證碼，不涉及沒有驗證碼的情況（神馬？沒有驗證碼？沒有驗證碼還討論什麼，要不人家不 care，要不人家已經胸有成竹有更牛逼的方法）。本文可能會與之前的某些文章有重合，可能與drops的“最嚴肅的安全原創平臺”氣質不符，請在家長指導下閱讀。

首先，我們來看下整個驗證碼實現的原理

圖一

• 1.客戶端發起一個請求
• 2.服務端響應並建立一個新的SessionID同時生成一個隨機驗證碼。
• 3.服務端將驗證碼和SessionID一併返回給客戶端
• 4.客戶端提交驗證碼連同SessionID給服務端
• 5.服務端驗證驗證碼同時銷燬當前會話，返回給客戶端結果

0x01 安全問題及案例

根據上面的實現流程，我們大概可以從四個方面入手，客戶端問題、服務端問題、驗證碼本身問題，還有一個驗證碼流程設計問題。

1. 客戶端問題

客戶端生成驗證碼

驗證碼由客戶端js生成並且僅僅在客戶端用js驗證

驗證碼輸出客戶端

輸出在html中（神一樣的程式設計師）

驗證碼輸出在cookie中，這個在烏雲中案例也是比較多的。

2. 服務端

驗證碼不過期，沒有及時銷燬會話導致驗證碼複用

這個是最常見的，烏雲上面有大量的案例。

沒有進行非空判斷

很多時候，我們會遺留掉了驗證過程中驗證碼為空的情況

比如去掉cookie中的某些值或者請求中驗證碼引數

產生的驗證碼問題集內的答案非常有限 


3. 其他型別驗證碼繞過

“除錯功能”還是設計缺陷？

“逗你玩”型別

有驗證碼，你輸入什麼 ，它都給你過，不驗證

萬能驗證碼（後門？）

4. 驗證碼太簡單，容易被機器識別

直接引用豬豬俠的兩個金融案例

0x03修改建議

梳理清楚驗證碼實現邏輯。（包括不限於驗證碼會話及時銷燬等） 驗證碼不要太簡單。扭曲、粘連等。

推薦Google的ReCaptcha

0x04 參考

https://www.owasp.org/index.php/Testing_for_Captcha_(OWASP-AT-008) http://www.mcafee.com/uk/resources/white-papers/foundstone/wp-attacking-captchas-for-fun-profit.pdf http://www.lijiejie.com/safe-issues-of-captcha/ http://*.wooyun.org

最後，祝大家愚人節快樂！