1. 任意密碼重置漏洞原理

廠商在對密碼修改功能設計的時候，未對修改密碼的憑證做嚴格的限制，導致可以被繞過進行任意的密碼修改。

2. 任意密碼重置漏洞產生原因

3. 任意密碼重置漏洞場景

3.1 驗證碼爆破

表現：

• 驗證碼四位，服務端未對驗證時間次數進行限制（出現次數比較多的地方）；
• 驗證碼六位，但是不過期（時間很久），并且沒有對驗證的次數進行限制；
• 驗證碼可以發送多次，而且每次都不會過期。

利用：使用burp的爆破模塊即可，或者自己編寫腳本。

修復：使用六位驗證碼，限制驗證碼認證次數。

案例流程：

• 重置密碼發送手機驗證碼
• 發現驗證碼只有四位
• 利用burp進行爆破
• 爆破成功
• 重置密碼

3.2 驗證憑證回傳

重置密碼時，憑證為發送到手機上的驗證碼，但是通過攔截發送驗證碼請求對應的Response包時，發現驗證碼在Response包中。

重點：注意是憑證，有時候可能返回包里面憑證可能在cookie里面或者也有可能在其他地方。

解決方案：修改包的返回規則

案例：DeDecms任意密碼重置

• DeDecms是用戶使用最多的PHP類cms系統，CMS 系統，即內容管理系統（Content Management System），此次該CMS的任意密碼重置漏洞，通過遍歷UID的方式獲取返回的靜態gourl跳轉地址，而CMS未對更改密碼的跳轉地址進行參數隱藏導致更改密碼的臨時密碼被泄露，泄露以后構造URL傳入臨時密碼，可以不需要任何驗證即可更改任意用戶密碼。

3.3 驗證憑證未綁是用戶

輸入手機號和驗證碼進行重置密碼的時候，僅對驗證碼是否正確進行了判斷，未對該驗證碼是否與手機號匹配做驗證。

表現：

• 1.任意賬號都能夠接收到驗證碼并能夠使用A手機的驗證碼，B可以拿來用
• 2.A賬號的修改密碼連接，B賬號可以拿來用

修復：

• 1.在服務器進行有效驗證，手機號和驗證碼在服務器進行唯─性綁定驗證。
• 2.在服務端限制驗證碼發送周期，設置時效，限制次數

常見案例：

• 首次登錄賬號之后需要你綁定郵箱、手機號等情況。
• 在綁定的時候修改綁定的賬號id即可把自己的手機號等綁定到別人的賬號上面。

3.4 跳過驗證步驟

成因：對修改密碼的步驟，沒有做校驗，導致可以輸入最終修改密碼的網址，直接跳轉到該頁面，然后輸入新密碼達到重置密碼的目的。

測試：首先使用自己的賬號走一次流程，獲取每個步驟的頁面鏈接，然后記錄輸入新密碼的對應鏈接。重置他人用戶時，獲取驗證碼后，直接進入輸入新密碼對應鏈接到新密碼的界面，輸入密碼重置成功。

3.5 憑證可預測

token可預測：使用郵件接受重置密碼的鏈接時，一般都會帶有一個token用于判斷鏈接是否被修改過。如果token可以預測，那么攻擊者可以通過構造鏈接來重置任意的用戶密碼。

表現:

• 1.基于時間戳生成的Token
• 2.基于遞增序號生成的token
• 3.基于關鍵字段生成的token
• 4.token有規律
• 5.驗證規則過于簡單

3.6 同時向多個賬戶發送憑證

將發送驗證碼的包截獲，修改字段添加多個賬戶，再發包。發現所寫的有效字段均發送了憑證。

4. 任意密碼重置經典案例

4.1 中國人壽某重要系統任意賬戶密碼重置

直接修改驗證返回包即可重置密碼，鏈接地址：https://cn-sec.com/archives/1557.html

其他相關案例：

• 中國人壽任意用戶密碼重置二
• 中國人壽任意用戶密碼重置（秒改）用戶保單信息全部泄漏

4.2 米鼠網設計邏輯的缺陷可重置任意用戶密碼

手機號沒有經過處理直接在請求包里看到，并且在源碼里找到重置密碼鏈接即可直接重置密碼。鏈接地址：http://cn-sec.com/archives/724.html

5. 權限繞過漏洞

越權漏洞的成因主要是因為開發人員在對數據進行增、刪、改、查詢時對客戶端請求的數據過分相信而遺漏了權限的判定。越權又可以分為兩種：水平越權與垂直越權。

5.1 水平越權

水平越權就是相同級別（權限）的用戶或者同一角色的不同用戶之間，可以越權訪問、修改或者刪除的非法操作。如果出現此類漏洞，那么將可能會造成大批量數據泄露，嚴重的甚至會造成用戶信息被惡意篡改。

比如同一公司的員工 A 和 B，分別只能查看自己的一些個人資料，但是如果系統存在水平越權漏洞，則 A 可以通過這樣個漏洞查看到 B 的資料。

水平權限漏洞一般出現在一個用戶對象關聯多個其他對象（個人資料、修改密碼，訂單信息，等）、并且要實現對關聯對象的 CRUD 的時候。開發容易習慣性的在生成 CRUD 表單（或 AJAX 請求）的時候根據認證過的用戶身份來找出其有權限的被操作對象 ID，提供入口，然后讓用戶提交請求，并根據這個 id 來操作相關對象。在處理 CRUD 請求時，往往默認只有有權限的用戶才能得到入口，進而才能操作相關對象，因此就不再校驗權限了。可悲劇的是大多數對象的 ID 都被設置為自增整型，所以攻擊者只要對相關 id 加 1、減 1、直至遍歷，就可以操作其他用戶所關聯的對象了。

案例：

• 一次水平越權，導致平臺兩萬人被修改密碼
• 小天才電話手表官網存在水平越權操作漏洞（影響用戶積分安全）

5.2 垂直越權

水平越權是相同級別的用戶之間的越權操作，而垂直越權則恰恰相反，是不同級別之間或不同角色之間的越權。

垂直越權又被分為向上越權與向下越權。比如，某些網站，像發布文章、刪除文章等操作是屬于管理員做的事情，假設一個低權限用戶或者根本沒權限也可以做相同的事情，這就叫作向上越權,

向下越權與向上越權恰恰相反，向下越權是一個高級別用戶可以訪問一個低級別的用戶信息。這樣做似乎沒錯，而且很多網站都是這么做的，包括低級別密碼也可以被高級別用戶掌控，但這樣做可以說是完全錯誤！因為即使權限再低的用戶都有他自己的隱私，可能用戶為了更方便，會將自己的銀行卡號與密碼記錄在網站中，這些信息都屬于用戶的隱私。

案例：

• Couchdb垂直權限繞過到命令執行