在邏輯漏洞中，任意用戶密碼重置最為常見，可能出現在新用戶註冊頁面，也可能是用戶登錄後重置密碼的頁面，或者用戶忘記密碼時的密碼找回頁面，其中，密碼找回功能是重災區。我把日常滲透過程中遇到的案例作了漏洞成因分析，這次，關註因重置憑證接收端可篡改導致的任意用戶密碼重置問題。

密碼找回邏輯含有用戶標識（用戶名、用戶 ID、cookie）、接收端（手機、郵箱）、憑證（驗證碼、token）、當前步驟等四個要素，若這幾個要素沒有完整關聯，則可能導致任意密碼重置漏洞。

前情提要：【傳送門】

案例一：接收端可篡改。請求包中包含接收端參數，可將憑證發至指定接收端。

密碼重置頁面，輸入任意普通賬號，選擇手機方式找回密碼。在身份驗證頁面點擊獲取短信驗證碼：

攔截請求，發現接收驗證碼的手機號為請求包中的參數：

直接篡改為攻擊者的手機號，成功接收短信驗證碼，提交驗證碼後，正常執行 3、4 步即可成功重置該賬號的密碼。

案例二：接收端可篡改。請求包中出現接收端間接相關參數，可將憑證發至指定接收端。

在密碼找回頁面，用攻擊賬號 test0141，嘗試重置目標賬號 2803870097 的密碼（對滴，你沒看錯，這兩個長得完全不像的賬號的確是同個網站的）。

在第一個首頁中輸入 test0141 和圖片驗證碼完成“01 安全認證”：

請求為：

輸入圖片驗證碼獲取短信驗證碼完成“02 身份驗證”：

請求為：

後續的 03、04 步不涉及用戶名信息，忽略。

全流程下來，客戶端並未直接提交接收短信驗證碼的手機號，多次嘗試可知，02 中出現的 user_name 用於查詢下發短信的手機號，用它可以間接指定接收端，那麽，它是否僅此作用而不用於指定重置密碼的賬號？如下思路驗證，先將 userName 置為 2803870097 完成 01 以告訴服務端重置的賬號，再將 user_name 置為 test0141 完成 02 以欺騙服務端將短信驗證碼發至攻擊者手機，順序完成 03、04 或許能實現重置 2803870097 的密碼。具體如下。

第一步，用普通賬號 2803870097 進行安全認證：

第二步，對普通賬號 2803870097 進行身份驗證：

攔截發送短信驗證碼的請求：

將 user_name 從 2803870097 篡改為 test0141，控制服務端將驗證碼發至 test0141 綁定的手機號：

test0141 的手機號成功接收到驗證碼 872502，將該驗證碼填入重置 2803870097 的身份校驗頁面後提交：

第三步，輸入新密碼 PenTest1024 後提交，系統提示重置成功：

第四步，用 2803870097/PenTest1024 登錄，驗證成功：

本文原創作者：yangyangwithgnu 轉自 www.freebuf.com

任意用戶密碼重置（二）：重置憑證接收端可篡改