發(fā)現(xiàn)IDOR漏洞的實例分析

這篇文章將為大家詳細講解有關發(fā)現(xiàn)IDOR漏洞的實例分析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

我非常喜歡搞IDOR漏洞，它通常被稱為不安全的直接對象引用或是越權，一般來說它的發(fā)現(xiàn)手段相對簡單，利用方式也不太難，但是對網(wǎng)站業(yè)務的危害影響卻比較嚴重。就我來說，我此前發(fā)現(xiàn)的一些高危漏洞大部份都屬于IDOR漏洞范疇之內。今天我們就來談談如何發(fā)現(xiàn)更多的IDOR漏洞。

IDOR漏洞介紹

IDOR，Insecure Direct Object reference，即"不安全的直接對象引用"，場景為基于用戶提供的輸入對象進行訪問時，未進行權限驗證。IDOR漏洞其實在越權（Broken Access Control）漏洞的范疇之內，也可以說是邏輯漏洞，或是訪問控制漏洞，國內通常被稱為越權漏洞。具體可點此參考。

然而，IDOR漏洞并不像增減和切換數(shù)字ID號那樣簡單，隨著應用程序的功能變得越來越復雜，它們引用資源的方式也形式多樣，這也意味著簡單的數(shù)字形式的IDOR漏洞在大多數(shù)網(wǎng)絡應用中變得越來越少。IDOR在Web應用中會以不同的方式體現(xiàn)出來，除了通常的簡單數(shù)字ID號之外，這里我們再來討論幾個值得注意的點。

去意想不到的地方尋找IDOR漏洞

別忘了編碼或是哈希過的ID號

當我們面對的是一個編碼ID時，總有可能用某種方法來把這個編碼ID進行解碼。如果Web應用使用的是哈?；螂S機的ID編碼，此時我們就要看看這個ID是否是可猜測的。有時Web應用使用的是一些不充分信息熵的算法（algorithms that produce insufficient entropy），其實經(jīng)過仔細分析后，我們是可以去預測ID號的。比如，我們可以注冊幾個賬戶去分析這種ID號的具體生成模式，然后就得總結得到其它用戶ID號的生成方法。

另外，也可以通過其它的API接口中來窺探一些泄露的隨機或編碼ID，比如Web應用的一些公開頁面，如用戶資料信息頁面、referer鏈接等。

比如，如果我找到一個API接口，它的功能是允許用戶通過一個編碼會話ID獲取到屬于自己的一些詳細私信內容，其請求格式如下：

GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

乍一看，其中的的會話ID（conversation_id）非常長，而且是隨機的字母數(shù)字組合序列，但是之后我發(fā)現(xiàn)，可以使用用戶ID號去獲取屬于每個用戶對應的一個會話列表！如下所示：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

而在這個會話列表中就包含了屬于用戶的會話ID號（conversation_id），又因為用戶ID（user_id）可以在每個用戶的資料頁面中公開找到，因此，組合利用這兩個ID號，我就能通過接口/api_v1/messages去讀取任意用戶和私信會話內容了！

如果無法猜測，可以嘗試創(chuàng)建

比如，如果對象引用號（object reference IDs）無法預測，可以看看能有什么操作來影響這種ID號的創(chuàng)建或鏈接過程。

給Web應用提供一個請求ID，哪怕它沒作要求

如果Web應用在請求動作中沒有ID號要求，那么可以嘗試給它添加一個ID號看看會發(fā)生什么。比如添加一個隨機ID號、用戶ID、會話ID，或是其它的對象引用參數(shù)，觀察服務端的響應內容。如下列請求接口用于顯示當前用戶所屬的私信會話內容：

GET /api_v1/messages

那要是把它換成這種樣式，會不會顯示出其它用戶的會話內容？

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

使用HTTP參數(shù)污染方法（HPP,HTTP parameter pollution）

用HTTP參數(shù)污染方式針對同一參數(shù)去給它多個不同的值，這樣也是可以導致IDOR漏洞的。因為Web應用可能在設計時不會料想到用戶會為某個參數(shù)提交多個不同值，因此，有時可能會導致Web后端接口的訪問權限繞過。雖然這種情況非常少見，我也從來沒遇到，但從理論上來說，它是有可能實現(xiàn)的。如以下請求接口：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

如果對它發(fā)起請求失敗，那么我們可以嘗試發(fā)起另外如下的請求：

GET /api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID

或是這種請求：

GET /api_v1/messages?user_id=ANOTHER_USERS_ID&user_id=YOUR_USER_ID

又或是換成這種把參數(shù)列表化的請求：

GET /api_v1/messages?user_ids[]=YOUR_USER_ID&user_ids[]=ANOTHER_USERS_ID

使用盲IDOR法（Blind IDORs）

有些場景下，易受IDOR漏洞影響的接口不會直接響應出來請求查詢的信息，但它們可以導致Web應用在其它方面泄露信息，如導出文件、郵件或是文本提醒等。

改變請求方法

如果某個請求方法無效，那么可以試試其它方法，如GET, POST, PUT, DELETE, PATCH…等，一個通常的技巧就是用PUT和POST進行互換，原因在于服務端的訪問控制措施不夠完善。

改變請求文件的類型

有時，切換請求文件的類型可能會導致Web服務端在授權處理上發(fā)生不同，如在請求URL后加上一個.json，看看響應結果如何。

如何提高IDOR漏洞的危害性

嚴重性IDOR優(yōu)先

這里，找IDOR漏洞時首先要考慮的是其對目標網(wǎng)站關鍵業(yè)務的影響程度，所以，讀寫型IDOR漏洞都屬于高危型IDOR漏洞。

按照狀態(tài)改變型state-changing (可寫型) IDOR漏洞來看，其導致的密碼可重置、密碼可更改或賬戶恢復等操作都會對目標網(wǎng)站關鍵業(yè)務造成嚴重影響，而那種更改郵件訂閱設置的IDOR漏洞影響就較低。

而對于狀態(tài)不可改變型non-state-changing（可讀型）IDOR漏洞來看，我們就要去關注它其中對敏感信息的處理操作，比如，對用戶私信會話的處理、對用戶敏感信息的處理，或是非公開內容的處理?？紤]Web應用中哪些功能會處理這些數(shù)據(jù)，然后有目標的去查找類似IDOR漏洞。

存儲型XSS（Stored-XSS）

如果把可寫型IDOR和self-XSS（需要受害者交互的XSS）結合，那么就有可能形成針對某個特定用戶的存儲型XSS（Stored-XSS）。它的用武之處在哪呢？比如，如果你發(fā)現(xiàn)了一個可以更改另外一個用戶購物車列表的IDOR漏洞，實際來說，該IDOR漏洞危害并不高，充其量只會引起受害者的一些麻煩，但如果把它和self-XSS配合利用的話，在某個用戶提交點，就能通過IDOR把XSS利用代碼傳遞給受害者瀏覽器端，最后的效果是，它就形成了針對特定受害用戶且無需交互的存儲型XSS了！

關于發(fā)現(xiàn)IDOR漏洞的實例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。