參考文章
概述
總結
重置密碼本身沒有問題i，但是在重置密碼中的驗證機制不夠完善。其產生的原因多種多樣，最主要的原因是**有邏輯上的漏洞，即沒有做到使用者、賬號、驗證碼三者統一進行驗證。
一般重置密碼流程：
總結為3步：
輸入要重置的使用者名稱/賬號
向該使用者繫結的手機號、郵箱等傳送驗證碼
操作者輸入驗證碼，證明自己是使用者本人
獲得修改密碼許可權
繁瑣的步驟核心目的是確認當前的操作者是該使用者本人。那麼就有四個因素特別重要，分別是：操作者、使用者賬號、使用者憑證、當前步驟。這四個因素需要相互驗證，在重置流程中，任何因素缺示都有可能被利用。
導致使用者賬號丟失、資訊丟失、財產損失等，對企業來講，任意賬號重置的漏洞將會丟失大量資料，失去使用者信任，嚴重妨礙企業業務，帶來巨大的財產損失。
該漏洞存在於使用者重置密碼一般流程的各個環節。
1. 驗證碼可爆破
在重置密碼的過程中，需要填寫驗證碼以證明操作者是使用者本人。無論是驗證碼是簡訊驗證還是郵件驗證碼（本質是一樣的），存在以下條件的，可以嘗試爆破。
驗證碼有效時間長
能夠反饋驗證碼的正確和錯誤
驗證碼錄入沒有次數限制
2. 簡訊驗證碼顯示在獲取驗證碼請求的回顯中
攻擊者知道被攻擊使用者的手機號碼，獲取簡訊驗證碼，抓包就可以在回顯中看到使用者收到的重置用的簡訊驗證碼。
3. 註冊手機號及簡訊驗證碼未進行匹配性驗證
攻擊者用自己手機號碼收到的重置用簡訊驗證碼可以重置其它使用者的密碼。
4. 使用者名稱、手機號碼、簡訊驗證碼三者沒有進行匹配性驗證
只驗證碼了手機號碼、簡訊驗證碼是否匹配，最終重置密碼是根據使用者名稱來重置的。攻擊者重置使用者a的密碼，獲取簡訊驗證碼的時候將手機號碼修改成自己賬號對應的，獲取到對應的正確簡訊驗證碼，然後輸入簡訊驗證碼，由於只驗證了手機號碼以及短息驗證碼是否匹配，從而可以成功繞過簡訊驗證碼限制來重置使用者a的密碼。
5. 驗證碼的驗證在本地客戶端進行驗證
通過修改請求回顯來繞過，常見重置姿勢之一，也可以用於繞過一些其它的前端驗證，比如儲存xss，引數的合法性驗證如果通過前端來完成，也可以用這種方法。
6. 重置步驟未進行校驗
這種一般發生在多個步驟重置的過程中，未對步驟1，2進行校驗，通過修改url直接繞過簡訊驗證碼的校驗步驟，直接進入重置頁面進行重置。
7. 重置請求未驗證身份
跟方法4差不多，最終重置請求沒有驗證使用者身份資訊。攻擊者用自己的手機號碼簡訊驗證碼走重置流程，最後一步重置請求抓包修改身份資訊為其它使用者的，從而進行其它使用者密碼的重置。
8. 登陸成功修改密碼功能平行越權
使用者登陸成功之後可修改自己的密碼，修改請求只需要輸入新密碼，請求中未驗證當前使用者的cookie、session、id等身份資訊，可以通過修改id等來重置其它使用者的密碼。
9. 未校驗身份資訊的唯一標識cookie資訊
重置請求引數中沒有使用者名稱、手機號碼、id等身份標識，唯一的身份標識是在cookie中。攻擊者用自己的賬號進行重置，最後重置請求中替換掉請求中的cookie進行其它使用者密碼的重置。
10. mvc資料物件自動繫結漏洞略
根據以上的挖掘方法，不難得出相應的防範方法
邏輯漏洞之重置密碼挖掘小姿勢
前話 感謝阿哲學長的分享。get到的新姿勢。一般重置密碼處大多要求驗證郵箱或者手機號碼。即可能導致如下漏洞 例項演示 重置密碼處抓包，然後post包如下圖所示 分析 要知道url處的 號碼跟資料報中的 號碼意義是不一樣的，url處的是傳送驗證碼的 號碼，而資料報當中的是要修改的使用者的 號碼。倘若碼...
任意使用者密碼修改重置漏洞修復
密碼修改功能常採用分步驟方式來實現，攻擊者在未知原始密碼的情況下繞過某些檢驗步驟修改使用者密碼。重置密碼過程一般是首先驗證註冊的郵箱或者手機號，獲取重置密碼的鏈結 一般會包含一串唯一的字串 或者驗證碼，然後訪問重置密碼鏈結或者輸入驗證碼，最後輸入新密碼。密碼重置機制繞過攻擊是指在未知他人的重置密碼鏈...
3322網域名稱重置任意使用者密碼的漏洞
3322網域名稱找回密碼時可以重置任意使用者的密碼。找回密碼功能傳送到email中的驗證碼和cookie中的乙個值繫結，未和需要找回的使用者名稱繫結，導致可用a郵箱中的驗證碼，驗證找回任意使用者。找回密碼時看了下，出現如圖這麼乙個token，直覺告訴我，這個發過去的驗證碼和cookie繫結了 於是，...