通過密碼找回漏洞能重置目標的賬號密碼，使得安全人員/***能查看被黑用戶的敏感信息。
注意測試密碼找回漏洞時最好先走一遍整個找回的流程
注意跳轉的鏈接和數據包里的內容
密碼找回步驟一般分為4步：
安全認證，通常是輸入賬號手機號郵箱等身份校驗，目標會下發驗證碼到接受端（手機或郵箱）密碼重置，輸入新密碼成功重置密碼找回邏輯含有用戶標志（用戶名、用戶ID、cookie）、接收端（手機、郵箱）、憑證（驗證碼、token）、當前步驟等四個要素，若這四個要素沒有完整關聯，則可能導致任意密碼重置漏洞。
第一類：重置密碼的憑證下發客戶端，導致重置憑證泄露W1
找回密碼時，抓取返回包后可輕易獲取作為重置憑證的驗證碼。
W2
用郵件找回密碼時，抓取返回包后可輕易獲取用于重置密碼的鏈接。
如圖從返回包中看到驗證碼是934456，手機接收的驗證碼也是如此；郵箱接受token同理。
第二類：所接受重置憑證的賬號由目標網站是從客戶端獲得，該賬號可以被修改導致任意密碼修改。W3
請求包中包含接收端參數（接受驗證碼的手機或者郵箱號），通過修改該參數可將憑證發至指定接收端。
W4
請求包中沒有可以直接修改的接收端相關參數，但是某些值間接影響接收端。
整個過程，并沒有直接提交接受重置憑證的手機號或者郵箱號，而是提交需要重置密碼的用戶名，猜測是通過用戶名查詢接受端的賬戶，從而指定接收端。
可以嘗試在第一步輸入想重置的賬戶名，第二步抓包將用戶名修改為自己的賬號用來接收憑證。
比如要找回AAA的密碼，在第一步安全認證中輸入該賬號，在第二步身份校驗時抓包修改AAA為BBB。
第三類：cookie混淆W5
通過cookie混淆不同賬號，實現重置任意用戶密碼在密碼重置的過程中，幾乎在數據包里看不到屬于自己賬戶的特征（用戶名或者ID），猜測和cookie里的某個值有關，假設其為A;
step1:
用攻擊者賬號進入密碼找回流程，查收重置驗證碼、通過校驗；
step2:
輸入新密碼后提交，burp抓包攔截；（這時攻擊者的賬號已和A綁定）
step3:
新開重置流程的首頁，在頁面中輸入想重置的賬戶；（這時想重置的賬戶和A重新綁定）
step4:
burp放包，理論上密碼已重置。
這個屬于好做不好理解的那種，從網上扒了個例子：
step1:
打開密碼重置鏈接http:xxxx/step_1.html
step2:
依次完成各個流程，來到第三步
step3:
重新打開http:xxxx/step_1.html,輸入任意手機號
step4:
繼續step2的流程，完成重置流程即可。
第四類：通過修改重置鏈接中的參數實現重置用戶密碼的目的W6
在接收到的重置連接中，有些參數與用戶名或者id相關，通過修改這些參數達到重置任意用戶密碼的目的。
如圖，這些參數多次測試發現于用戶名有關，可以嘗試修改達到任意用戶密碼重置的目的。
第五類批量發送驗證碼批量爆破賬號W7
很多網站在在驗證環節如果輸出三次驗證碼就會出現限制措施
比如限制時間或者重新發送驗證碼，這無疑給爆破驗證碼增添難度
那換個思路：
前提條件：
擁有目標網站大量賬號（假設驗證碼是5位數字，驗證碼輸錯3次就會出現限制）
step1:
同時使用這些賬號找回密碼，這樣就會有大量00000-99999直接的驗證碼被生成
step2：
隨便指定一個符合規則的驗證碼比如66666去爆破賬號，理論上而言，總會有一個賬號是這個驗證碼
掃描下方二維碼！
邀你進內部交流群，領靶場鏈接！工具！零基礎體制化視頻教程
