這是一次針對某SRC廠商某業務的一個登陸頁面的測試

文中相關漏洞現均已修復 提取其中思想精髓 分享給諸位師傅

梅開一度

開局一個登陸框，正常情況下，我隨手一個admin/123456打過去，如果提示"賬號不存在",或者"密碼錯誤"。再立馬掏出我祖傳的用戶遍歷及弱口令字典。定向爆破。

但此時提示"賬號或密碼錯誤",就老老實實去注冊，走正常流程了。

burp代理開啟，記錄下所有數據包，并對其中可疑參數記錄標記。

輸入手機號， 獲取驗證碼，這時已然收到了真實的驗證碼，但是為了獲取更多的隱藏參數以及盡可能的走全業務邏輯，這里隨便輸了一個123456，故意讓其報錯。

果然返回驗證碼錯誤，但是同時數據包中也反悔了正確的驗證碼。

至此，任意用戶注冊一枚到手，提交到src很快啊，給了三位數的賞金。

但我并不滿足于此，正所謂，不像挖高危的安福仔不是一個好的白帽子。

很自然的想到注冊的地方都出問題了，那找回密碼的地方呢，是否也同樣存在驗證碼就回顯在響應包中呢？

抱著試一試單車變摩托的心理，嘗試卻發現返回包直接返回false，嘗試將返回包修改為true，仍無法繞過前后端的校驗。

梅開二度

兩周過去后，發現已經修復了，但是返回包的數據修復的很奇怪，刪了好多東西，就只剩下一個flag參數了。

{"flag": "error"}

同樣想當然的去嘗試了一下將"error"修改為"success"等，無果又測試了一遍，還是沒問題。看來真的是修復了，但總感覺哪兒還是有問題。

掏出之前保存的數據包，翻回到之前的數據包，對照分析了一下，這次果然有了新的發現。

第一次測試時的注冊接口 GET /register/xxx HTTP/1.1 Host: xxx.xxx.com第二次測試時的注冊接口 GET /registerPage HTTP/1.1 Host: xxx.xxx.com

好家伙，接口都直接換了，難怪感覺到響應包哪里不對勁呢.

啪，很快，我直接用原來的接口放上原來的payload打了過去，很快啊，驗證碼又返回在了響應包中。

及時提交到某src，這波又給了三位數的賞。

這里推測如下:

是業務那邊怕直接修改源碼出差錯后會影響原來正常邏輯，所以備份了一下修改了一個新的接口去替換舊的那個接口，而忘記將備份的那個舊的接口修改并及時刪除，依然存在著。

這里bypass也就是通過構造請求包去請求舊的那個接口，然后得到回顯。

一點點小tips

所以在測試過程中比較重要的數據包要有意識的保留及整理，待復查的時候，要看看在原漏洞觸發處是不是有了新的頁面或者調用了新的接口，以及舊的接口還在否。

是的話，用原來的url，接口或者exp直接打一下，看能不能撿漏(當然這種情況絕大多數會是邏輯漏洞吧)

梅開三度

又是兩周過去啦，又是我，又是這個站，又是這個登錄框
這次舊接口問題已經被修復，無法再通過就接口直接打驗證碼了。
啪,很快，靈關一閃，會不會這里只是校驗了接口和接口對應的驗證碼是否一致，而不校驗手機號的呢？

接口對應的驗證碼是否一致，而不校驗手機號的呢？

說干就干，先在注冊填寫手機號碼獲取驗證碼的時候，使用自己的手機號進行接口驗證碼。

發送驗證碼之后馬上把手機修改成要任意注冊的手機號碼(很關鍵)

這里的驗證碼填寫的是剛剛155xxxx3531接收到的驗證碼，而131xxxxxxxx這個號碼是沒有獲取過驗證碼的。

點擊注冊，真的就直接注冊成功了，驗證了上面的想法是正確的，這里只驗證了驗證碼接口和對應的驗證碼，并沒有校驗手機號是否為接收驗證碼的那個手機號。

當成功產出一個漏洞時，要思考的有兩件事，即橫向或縱向上擴展成果。

橫向

既然這里沒對注冊手機號和驗證碼同時驗證，如果驗證碼還沒有失效的話，批量注冊一下？

將手機號的后兩位作為變量，批量跑了一下也都成功了(這里設置兩位作為變量，只是想證明漏洞真實存在，盡可能多的減少對業務的影響).

又是一波三位數的賞金。

梅開四度

梅都開三度了，還是三位數獎金，也是醉了。。。
不想挖高危的安服仔不是一個好的白帽子，繼續搞。

縱向

很容易想到既然驗證碼沒有與實際接收手機號的號碼綁定起來。那它在整個賬號體系里對應的功能點可不止注冊哦。對的，還有密碼找回嘛。

后米看就是同樣的玩法了。

在找回密碼處填寫手機號碼獲取驗證碼的時候使用自己的手機號進行接口驗證碼，得到驗證碼后將自己的手機號替換為你想改密碼的手機號。短信驗證碼就輸自己手機號接收到的那個。

抓包操作如下:

bur攔截到如上所示的包，不要放行。Ctrl+r到repeater模塊，修改mobile為你的目標手機號。

發包，目標賬號的密碼被修改成功。

這里繼續嘗試批量問題，也仍存在，即批量修改任意用戶賬號密碼。

抱著單車變摩托的心理，提到src，沖。

然而，大意了，不講武德，耗子尾汁。

我淦，萬萬沒想到。可能前三個洞提的導致這個資產進入了保護期。

梅開五度

十幾天后，抱著試一試的心理，結果不出所料，怕啥來啥，洞還是給修復啦。
沒辦法，誰讓咱頭鐵，接著搞。

壓箱底的祖傳技巧

這里分享一個壓箱底的祖產技巧，不保證百分百能成功，但遇到這種情況，值得一試。

F12切換到移動設備調試

?

好家伙，界面感覺都和pc端的不太一樣了，然后抓包，發現接口果然也不太一樣。
后面就是和梅開四度里的玩法一樣了，如下圖

通過切換訪問設備的標識成功bypass，收獲批量修改任意用戶賬號密碼一枚。

提交到SRC后，最終get到了四位數的賞金。

總結：

心細挖天下！！！

梅開一度：盡可能的走一遍完整的業務邏輯流程，盡管你覺得這里99.99%的可能性不會出錯。

梅開二度:整理好測試中比較重要的數據包，揣測業務的修復心理，嘗試用原來的payload打原來的接口。

梅開三度:思考漏洞產生表象后的觸發原理，進而擴大漏洞的利用面。

梅開四度:同一個漏洞對應在業務體系里的對應的功能觸發點可能不止一處。

梅開五度:不同設備的訪問請求(User-Agent),可能會導致實現同一業務功能的接口不同。

?

總結

以上是生活随笔為你收集整理的记一次短信验证码的“梅开五度”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。