實現一個業務功能，也有着很多不同的實現方式，當業務邏輯考慮不嚴謹的時候，同一個業務功能模塊存在着很多漏洞場景，如密碼重置漏洞、商城支付漏洞等。
本文分享一個有意思的案例，通過漏洞組合實現任意密碼重置，同時，也是驗證碼驗證一次有效的利用場景。
1、在這個密碼重置模塊裏面，只需輸入手機號和手機驗證碼即可進入修改密碼界面，看到這個界面，很多人會嘗試暴力破解，但會發現驗證碼僅能使用一次，爆破成功，但輸入的時候已經失效了，怎麼辦？
2、 我們填寫用戶的手機號碼，獲取驗證碼，隨意輸入幾個驗證碼，抓包：
我們注意到返回的是失敗，如果返回成功，是什麼樣子呢？通過測試，如果驗證碼輸入正確，返回{"data":"success"}。
3、修改返回包爲{"data":"success"}，即可繞過驗證碼驗證，進入修改密碼界面。
4、在這裏，輸入兩次新密碼，提示密碼修改失敗。查看HTTP交互過程，Token值不變。猜想：如何把Token變成有效的，這樣才能修改成功。
{"Token":"eyJhbGciOiJIUzI1NiJ9.eyJpczMiOiJmYW5ydWFuIiwiaWF0IjoxNTYyOTI0MzUxLCJzdWIiOiIxaDA0MDI5OSIsIgp0aSI6Imp3dCJ9.Mo0KuEZwOuT6pPsJCydgKD-qVjIieaVAWDX7tchk4NY","newPassword":" IGFiY2RlMTIz"}5、這裏，我們利用系統的另一個缺陷，因對手機驗證次數沒有限制，遍歷000000-999999區間，暴力破解手機驗證碼，成功後返回success
6、此時，輸入用戶新密碼，保存後修改成功。
簡單來說，這個漏洞場景是這樣：
A、前端驗證繞過可以直接進入密碼修改界面，但Token無效，無法成功修改密碼。
B、手機驗證碼可以暴力猜解，但驗證碼一次失效，爆破出來再輸入驗證碼無效。
這個時候，通過A+B的漏洞組合，利用前端驗證繞過進入修改密碼界面，暴破驗證碼使Token生效，就可以實現任意密碼重置漏洞 。
漏洞往往就隱藏在一些細節裏面，在滲透測試中，去分析請求中的每個參數，並注意檢查頁面返回的源代碼。比如，當參數拼接到SQL中執行，就存在SQL注入，當參數直接輸出到前端，就存在XSS跨站腳本。
似乎很難再找到人去分享，發現一種新的漏洞利用場景的喜悅。
----致那些曾經一起玩滲透的朋友。
