你的 Java 驗證碼和登入程式中可能也存在這樣的漏洞

進行這個整理，是因為在XXX專案的時候，發現登入模組的忘記密碼功能，在驗證使用者身份的時候是透過手機驗證碼驗證的。透過修改響應包的返回引數值，可以繞過驗證，進入第三步的密碼重置。還有最近測試的一個sso登入，也存在驗證碼問題。

之前的測試中也遇到過類似的驗證碼繞過的漏洞，所以對驗證碼繞過方法進行一個總結，以及關於登入模組可能會存在的邏輯漏洞進行一個小整理。

其實，會出現驗證碼的地方，也就是校驗使用者身份處，比如，登入、忘記密碼、註冊、繫結、活動領取、反饋處等。而登入模組中可能存在的邏輯漏洞，無非就是使用者列舉、任意使用者密碼重置，當然認證繞過也是邏輯漏洞，這個我們暫且放在驗證碼裡面。

繞過簡訊驗證碼的方法以及例子

透過修改響應包的返回值繞過

這種是使用者端根據返回的值，來確定是否進行下一步。比如傳送成功返回state的值是success，失敗是false，然後客戶端根據state的值，來確定下一步的動作。這樣，我們可以透過修改響應包，繞過驗證。

例1

比如忘記密碼處：第二步中，對使用者的身份進行簡訊驗證，可透過修改響應包，將error換為ok即可繞過身份驗證，到設定密碼處。

例2

註冊處，驗證手機驗證碼處，透過修改響應包，或替換為自己的手機號，繞過驗證碼的限制，造成使用他人手機號進行註冊。

例3

有些登入也存在類似的問題，隨便輸入賬號密碼，攔截返回的響應包，將包替換為A賬號正確的登入返回的響應包（前提是，A賬號的cookie是有效的），即可登入到A賬號。這種也是客戶端，根據響應包的值，來決定下一步動作。

服務端未對身份做校驗

這種比較少，因為算是功能問題，在驗證身份時，未對答案進行校驗。就是隨便輸入，就能進入下一步。

例4

忘記密碼處，第二步中，選擇其他方式找回，透過密保找回，未對密保答案進行驗證，隨便輸入答案，即可跳轉到設定密碼處。

驗證碼置空繞過驗證

簡訊驗證碼處，隨便輸入其他，驗證碼錯誤，而置空卻不校驗，則可以透過置空繞過

例5

我的==>登陸==>簡訊驗證碼登陸登陸時抓包把code（驗證碼欄位）值置為空，即可登陸任意賬戶

傳送簡訊時，將手機號替換為自己的手機號獲取驗證碼

當修改別人的資訊時，需要簡訊認證時，在傳送簡訊時，我們可以嘗試，將手機號替換為自己的，來獲取簡訊驗證碼。如果服務端只是檢查驗證碼是否正確，而不是進行手機號和驗證碼匹配的話，或者只是匹配發送簡訊手機號和驗證碼，我們就可以繞過認證。

例6

忘記驗證碼，驗證身份時，在傳送簡訊時，攔截，將手機號替換為我們自己的，傳送。然後再輸入得到驗證碼，驗證，如果此時只是驗證碼驗證碼是否正確，即可繞過。

但是，若驗證傳送手機號和驗證碼是否匹配時，我們可以在填好驗證碼，提交時，攔截，將手機號再次改為我們自己的，即可繞過。

允許一次給多個手機號傳送簡訊，獲取驗證碼

在給手機發送簡訊驗證碼時，比如phone=13211111111，我們同時向多個手機號傳送簡訊，用逗號隔開，即phone=13211111111，13233333333，可傳送成功。所有手機收到相同的驗證碼，後面在驗證驗證碼時，如果可以匹配成功的話，即可繞過驗證碼。另外，這樣可以向大量手機號傳送，造成費用增加。

例7

註冊處，在獲取簡訊驗證碼時，抓包將mobilePhone的值改為多個手機號，並用逗號分隔，可成功多個手機號傳送簡訊驗證碼。

簡訊驗證碼太短，爆破繞過

有的簡訊驗證碼位數太短，採用4為純數字的簡訊驗證碼作為登入認證的憑證，這樣若是沒有對次數限制或存在圖形驗證碼的話，就很容易採用工具進行爆破驗證碼登入。

例8

重置密碼處根據簡訊驗證碼，是否正確來確定是否能修改成功，而且驗證碼是四位純數字的，可以進行爆破。code=4935&mobile=18556530793&pwd=123456a

利用介面標記繞過簡訊限制

註冊、忘記密碼、修改密碼處，均存在傳送簡訊驗證，可能會設定引數值的不同，來判斷是執行什麼樣的功能。比如type=1是註冊，type=2是忘記密碼，type=3是修改密碼等。我們可以透過修改引數值，來繞過一分鐘內只發送一次限制，達到簡訊轟炸的目的。

例9

註冊頁面處，URL/public/getPhoneVerifyCodeWithCheckPicVerCode正常邏輯是驗證圖片驗證碼，正確後，再發送手機驗證碼。將請求修改為/public/getPhoneVerifyCode，從而繞過圖片驗證碼的驗證機制。

例10

註冊頁面處，傳送簡訊驗證碼處，可以結合上例中的繞過圖形驗證碼的機制，發現smsType的值，不同時，可以繞過180秒限制。可以遍歷修改smsType的值，從而造成簡訊炸彈。

例11

註冊，在傳送手機驗證碼或郵箱驗證碼處，r=2時，連續傳送驗證碼，會提醒“重新輸入驗證碼”，說明驗證了圖形驗證碼。但是r=5時，可以傳送成功，連續傳送時，提醒“一分鐘內不允許多次傳送”。

僅有一分鐘內不允許多次傳送驗證碼限制，但是並未對圖形驗證碼進行校驗，可以透過甚至頻率，使其，兩分鐘傳送一次，同樣可以造成簡訊/郵箱轟炸。

例12

繫結手機號處，正常的傳送簡訊的URL是sendSMS4Mobile，嘗試修改URL，是否存在其他傳送介面。經過不斷嘗試，sendSMS介面同樣可以傳送簡訊。

利用空格繞過簡訊條數限制

透過在引數值的前面加上空格，進行繞過一天內傳送次數的限制。比如，mobile=13211111111，一天可以傳送10次，超過10次今天將不再發送，第二天才可以繼續傳送。但是，可以透過在手機號前面或後面加上空格又可以傳送10次。比如，mobile= 13211111111，前面加個空格，就可以再次傳送成功。

透過修改cookie值繞過簡訊次數

有些傳送簡訊的次數是根據cookie值進行判斷，（此cookie值並不是登入狀態下的cookie而不是普通狀態下的），利用當前cookie值來驗證傳送次數的話，很容易被繞過。

例子https：//bbs。ichunqiu。com/forum。php？mod=viewthread&tid=27614

之前有個登入賬號密碼錯誤三次，就會出現圖形驗證碼。但是當關閉瀏覽器，重新開啟，再登入，又會有三次機會，當時，蘆浩分析得出是根據cookie判斷的，然後透過，不斷獲取新的cookie，來繞過三次限制，進而進行賬戶密碼列舉。

http：//wiki。iflytek。com/pages/viewpage。action？pageId=128550855修改IP繞過簡訊/郵箱轟炸

有些是驗證當前IP，如果當前IP短時間內獲取簡訊或郵件頻繁或達到一定的次數，會鎖定當前IP，這時可以嘗試透過修改IP或代理IP來進行繞過限制

利用大小寫繞過郵箱轟炸限制

有時候驗證碼是傳送到郵箱的，可以透過修改郵箱後面字母的大小寫繞過限制。比如：email=

@qq.com，當次數達到限制時，將字母修改為大寫：

email=

@Qq。com，即可繞過。

修復建議：

1、服務端對驗證碼進行校驗，簡訊驗證碼應該根據使用者存在資料庫中的手機號收到的驗證碼進行匹配驗證。

2、增加複雜的圖形驗證碼，且一次性有效

3、限制一天內傳送的上限

使用者列舉

在驗證使用者身份的時候，或判斷使用者是否已註冊時，若驗證碼處理不當、或錯誤提醒明確，都可能存在使用者列舉。

缺乏/未驗證的圖形驗證碼，造成使用者列舉

例1

忘記密碼處，首先驗證使用者身份，雖然此處有圖形驗證碼，但是，圖形驗證碼不重新整理，即不是一次有效，透過攔截請求，發現，並未對驗證碼進行驗證。可以進行使用者列舉

例2

手機驗證碼登入處，在校驗手機號是否是已註冊的手機號時，繫結的手機號和未繫結的手機號，返回的響應包不同，而且未增加圖形驗證碼校驗，可對已繫結的手機號列舉。

例3

忘記密碼處，圖形驗證碼引數為imageValidCode，重複放包時，發現，驗證碼是一次有效的，經過嘗試，發現刪除imageValidCode引數，可以繞過驗證碼的驗證機制，從而進行使用者列舉。爆破已註冊的賬號。

提醒明確，造成的使用者列舉

一些錯誤，提醒明確，比如登入時，輸入賬號、密碼，均錯誤的情況下，提醒賬號錯誤；賬號正確、密碼錯誤時，提醒密碼錯誤，從而可以進行列舉。

例4

登入處，輸入錯誤的賬號，會提醒使用者不存在；錯誤的密碼，會提醒密碼不正確。可根據提示，進行使用者、密碼列舉。

例5

關聯賬戶繫結==>切換賬戶處，根據loginname的值，返回對應賬號的繫結的手機、郵箱等個人資訊。當loginname為不存在的賬號時，響應包為“操作失敗”，而且請求包中，僅有loginname這一個引數，可以對其進行使用者列舉。

例6

在密碼修改功能，會驗證原始密碼和賬號的正確性，賬號、密碼都正確時resCode=00100000，賬號錯誤resCode=00100001，msg為空。賬號正確，密碼錯誤時，msg提醒原始密碼錯誤。可以進行列舉其他賬號、密碼。比如，可以列舉密碼為1111的賬號。

修復建議：

1、 模糊提醒

2、 增加複雜的圖形驗證碼，對於登入後可能存在的列舉，增加token，且一次性有效

3、 限制請求頻率，錯誤一定次數，鎖定賬號一段時間

任意使用者密碼重置

造成任意使用者密碼重置，主要發生在修改密碼、忘記密碼處，在邏輯上處理不嚴謹造成的。比如，忘記密碼處，先驗證身份，驗證透過才允許密碼重置，前面驗證很嚴謹，不能繞過，但是第三步不嚴謹，比如僅根據賬號來進行密碼重置，那就很可能存在任意使用者密碼重置。

例1

忘記密碼處，最後一步更新新密碼處，透過抓包，發現僅是根據賬號進行密碼修改，那麼修改account為任意存在的賬號，就可以修改任意賬號的密碼。

修復建議：

邏輯上要嚴謹，不能說前面校驗現在要重置密碼的人是A後，就認為後面的操作都是A的。還是要進行校驗確認的。