越權漏洞（e.g. IDOR）挖掘技巧及實戰案例全匯總

• 2019 年 10 月 10 日
• 筆記

1、漏洞理解

Insecure Direct Object reference (IDOR)不安全的直接對象引用，基於用戶提供的輸入對象直接訪問，而未進行鑒權，這個漏洞在中國被稱作越權漏洞。

IDOR其實在越權（Broken Access Control）漏洞的範疇之內，嚴格來說越權的含義更廣一些。它可以說是邏輯漏洞，也可以說是一個訪問控制問題，細分的話可以將其分為URL層訪問控制和數據層訪問控制。

2、挖掘技巧

1）關注功能

檢查任何涉及的敏感ID功能處替換：包括普通的增刪改查、上傳、共享及密碼重置，密碼更改，帳戶恢復等處的id值，不同功能處影響也不一樣：

P1 – 賬戶接管，訪問非常重要的數據（如信用卡）

P2 – 更改/刪除其他用戶的公共數據，訪問私人/公共重要數據（如門票，發票，付款資訊）

P3 – 訪問/刪除/更改私人數據（有限的個人資訊：姓名，地址等）

P4 – 訪問任何不重要的數據

2）漏洞分類

a、簡單：直接標識符

關注「id」，「user_id」，「value」，「pid」，「post_id」等參數處、目錄處，關注任何場景每一個可能決定用戶許可權的參數值。通過加和減1提交整數值，看是否可以看到本不該看到的數據，若返回403拒絕訪問很可能說明沒有漏洞。

b、複雜：隨機標識符

遇到某些參數使用哈希值（如UUIDs），可以嘗試解碼編碼值，或尋找參數值泄露（特定返回包或頁面源程式碼）, 測試時通常創建兩個帳號並替換參數值，查看是否可以操作成功，若參數過多可使用comparer模組篩選處不同參數：

3）越權訪問：

廣義上講，越權就是「看到當前用戶本不該看到的數據，執行本不該執行的操作」。

用戶間越權：

比較管理員和普通用戶、用戶之間存在許可權差異處，包括：

1、 GET：抓取對目錄及類名的請求（URL層）

2、 POST：關注任何請求/API，具體的方法（數據層）

單用戶內部越權：

1、 灰化按鈕，審查元素繞過前端檢驗

2、 單業務處上下條數據之間是否存在許可權差異（編輯/查看）

3、 多業務是否公用方法可以篡改許可權或數據

4）更多

結合HPP（傳送門），self-xss等漏洞將低危漏洞升級為高危漏洞。

3、實戰案例

1）微軟找回密碼IDOR

微軟招聘網站通過郵箱找回密碼處，ID未進行用戶許可權校驗，導致通過提交攻擊者郵箱和遍歷id方式重置任意用戶密碼。

2）雅虎任意評論刪除

雅虎評論刪除url地址為：

https://tv.yahoo.com/_xhr/contentcomments/delete_comment/

參數為：

comment_id=139967299182-588b2cdd&content_id=485d5605ea9&crumb=DcUNKWnp7%2F8

其中comment_id代表不同用戶的id，使用另一個賬戶victim登錄並評論，抓取comment_id並替換，返回200的json數據：

但再次嘗試其他評論時，卻返回401鑒權失敗：

經過反覆測試，發現只有攻擊者是第一個評論者時才能刪除後面的任意評論，開發者遺漏了對第一個評論者的鑒權驗證。

3）Twitter信用卡刪除IDOR

Twitter支付方法頁面中信用卡的刪除功能，URL如下：

https://ads.twitter.com/accounts/[account id]/payment_methods

進行刪除操作時會發送ajax的post請求為：

請求報文只有兩個參數，重點是了解參數代表的含義：account指Twitter賬戶id，id指綁定的信用卡id，同樣的操作，登錄另一個Twitter賬戶獲取賬戶id和綁定的信用卡id，進行替換，頁面響應是「403 forbbiden」，但實際卡已經刪除。

類似的還有YouTube的任意評論移動漏洞，價值3k美元，漏洞發生在其他人在你的影片下評論，點擊查看：

請求數據包為：

需關注的參數是comment和video，含義較明顯，依舊嘗試替換id，如果將VIDEO_ID更改為任何其他影片ID，會出現錯誤；但如果保持VIDEO_ID不變只改變COMMENT_ID，其他的評論將會出現在你的影片下。

4、防護手段：

任何一個端點/介面/請求都應該進行鑒權操作，有效的驗證機製為將參數中的每個關鍵id都和當前登錄用戶身份及許可權進行校驗，即使是系統已有相關鑒權操作，也很容易遺漏某些細節。