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

前言

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

密碼找回邏輯含有使用者標識（使用者名稱、使用者 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 登入，驗證成功：

防禦措施方面，一定要將重置使用者與接收重置憑證的手機號/郵箱作一致性比較，通常直接從服務端直接生成手機號/郵箱，不從客戶端獲取。