0x00 前言
其實drops里面已經有小胖胖@小胖胖要減肥 和A牛@insight-labs 相應的文章，只是覺得應該有個入門級的“測試用例”。本文不涉及OCR，不涉及暴力四六位純數字驗證碼，不涉及沒有驗證碼的情況（神馬？沒有驗證碼？沒有驗證碼還討論什么，要不人家不 care，要不人家已經胸有成竹有更牛逼的方法）。本文可能會與之前的某些文章有重合，可能與drops的“最嚴肅的安全原創平台”氣質不符，請在家長指導下閱讀。
首先，我們來看下整個驗證碼實現的原理
圖一
- 1.客戶端發起一個請求
- 2.服務端響應並創建一個新的SessionID同時生成一個隨機驗證碼。
- 3.服務端將驗證碼和SessionID一並返回給客戶端
- 4.客戶端提交驗證碼連同SessionID給服務端
- 5.服務端驗證驗證碼同時銷毀當前會話，返回給客戶端結果
0x01 安全問題及案例
根據上面的實現流程，我們大概可以從四個方面入手，客戶端問題、服務端問題、驗證碼本身問題，還有一個驗證碼流程設計問題。
1. 客戶端問題
客戶端生成驗證碼
驗證碼由客戶端js生成並且僅僅在客戶端用js驗證
WooYun: 南開大學信息門戶網站設計不當可以爆破用戶密碼（利用密碼猜用戶）
驗證碼輸出客戶端
輸出在html中（神一樣的程序員）
WooYun: 某會考報名系統驗證碼繞過可暴力破解（可導致用戶信息泄露）
驗證碼輸出在cookie中，這個在烏雲中案例也是比較多的。
2. 服務端
驗證碼不過期，沒有及時銷毀會話導致驗證碼復用
這個是最常見的，烏雲上面有大量的案例。
WooYun: 蘇寧易購某系統后台多個超級管理員弱口令（驗證碼可重復利用）
沒有進行非空判斷
很多時候，我們會遺留掉了驗證過程中驗證碼為空的情況
比如去掉cookie中的某些值或者請求中驗證碼參數
產生的驗證碼問題集內的答案非常有限
WooYun: 139郵箱圖驗證碼繞過漏洞（目前圖形驗證碼的可預測案例）
3. 其他類型驗證碼繞過
“調試功能”還是設計缺陷？
WooYun: 正方教務管理系統設計錯誤，可繞過驗證碼進行暴破或掃弱口令
“逗你玩”類型
有驗證碼，你輸入什么 ，它都給你過，不驗證
萬能驗證碼（后門？）
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
最后，祝大家愚人節快樂！