驗證碼安全基礎

常見的驗證碼問題：

問題一：驗證碼是否出現的判斷邏輯放在客戶端瀏覽器

有些系統預設不顯示驗證碼，而是在使用者校驗錯誤一定次數之後再出現。 那如何判斷使用者已經錯誤幾次了呢？沒有經驗的開發可能這樣做： 在cookie中寫入一個標記，比如loginErr = 1，後續錯誤累加 在session中寫入一個標記，例如loginErr = 1，後續錯誤累加 問題在於，要是惡意訪問者不帶Cookie提交HTTP請求呢？或者不更新Cookie中的loginErr的值反覆提交呢？

程式因為無從獲取Cookie/sessionID，會認為使用者是首次訪問。無論什麼時候，驗證碼都不會出現！

問題二：驗證碼不過期，單個驗證碼反覆可用

多數時候，驗證碼在web伺服器上對應一個session值。

如果完成一次校驗，不標記這個session已失效，就會造成同一驗證碼反覆可用。

此時，驗證碼將不再有用。

惡意訪問者在cookie中帶固定的sessionID和固定的一個驗證碼字串，即可輕鬆爆破。

還有一種很常見的程式碼實現，更新session的工作是通過重新下載驗證碼達到的。

而開發人員容易犯的一個失誤，是把更新session的任務交給客戶端瀏覽器。

比如302重定向，甚至是通過js、meta refresh重定向頁面，來引導使用者重新下載驗證碼。

這些做法實際是錯誤的，要是使用者攔截了重定向，沒有發出新的下載請求呢？ 這樣，上次的驗證碼是否還可以使用？

基本的認知是：一個驗證碼，只能使用一次。使用之後，立即過期，不可再次使用。

問題三：將驗證碼內容輸出到客戶端

無論出於什麼考慮，都不應該把驗證碼的內容傳送到客戶端cookie、或輸出到response headers的其他欄位。

比如，寫入驗證碼的MD5值、 Base64轉碼等，太容易被逆向破解，得到原值。

即便是加固定salt後輸出，都是很不好的。

問題四：驗證碼太弱

一般，出現邏輯錯誤的驗證碼，同樣存在太弱的通病，使用開源的tessertact OCR引擎，不經任何訓練，不人工去噪處理，也能識別網際網路上的大部分驗證碼！