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

成都創(chuàng)新互聯(lián)是一家從事企業(yè)網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、網(wǎng)站制作、行業(yè)門戶網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)制作的專業(yè)的建站公司，擁有經(jīng)驗(yàn)豐富的網(wǎng)站建設(shè)工程師和網(wǎng)頁設(shè)計(jì)人員，具備各種規(guī)模與類型網(wǎng)站建設(shè)的實(shí)力，在網(wǎng)站建設(shè)領(lǐng)域樹立了自己獨(dú)特的設(shè)計(jì)風(fēng)格。自公司成立以來曾獨(dú)立設(shè)計(jì)制作的站點(diǎn)成百上千。

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

IDOR漏洞介紹

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

然而，IDOR漏洞并不像增減和切換數(shù)字ID號(hào)那樣簡單，隨著應(yīng)用程序的功能變得越來越復(fù)雜，它們引用資源的方式也形式多樣，這也意味著簡單的數(shù)字形式的IDOR漏洞在大多數(shù)網(wǎng)絡(luò)應(yīng)用中變得越來越少。IDOR在Web應(yīng)用中會(huì)以不同的方式體現(xiàn)出來，除了通常的簡單數(shù)字ID號(hào)之外，這里我們?cè)賮碛懻搸讉€(gè)值得注意的點(diǎn)。

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

別忘了編碼或是哈希過的ID號(hào)

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

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

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

GET /api_v1/messages?conversation_id=SOME_RANDOM_ID

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

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

而在這個(gè)會(huì)話列表中就包含了屬于用戶的會(huì)話ID號(hào)（conversation_id），又因?yàn)橛脩鬒D（user_id）可以在每個(gè)用戶的資料頁面中公開找到，因此，組合利用這兩個(gè)ID號(hào)，我就能通過接口/api_v1/messages去讀取任意用戶和私信會(huì)話內(nèi)容了！

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

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

給Web應(yīng)用提供一個(gè)請(qǐng)求ID，哪怕它沒作要求

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

GET /api_v1/messages

那要是把它換成這種樣式，會(huì)不會(huì)顯示出其它用戶的會(huì)話內(nèi)容？

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

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

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

GET /api_v1/messages?user_id=ANOTHER_USERS_ID

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

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

或是這種請(qǐng)求：

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

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

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

使用盲IDOR法（Blind IDORs）

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

改變請(qǐng)求方法

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

改變請(qǐng)求文件的類型

有時(shí)，切換請(qǐng)求文件的類型可能會(huì)導(dǎo)致Web服務(wù)端在授權(quán)處理上發(fā)生不同，如在請(qǐng)求URL后加上一個(gè).json，看看響應(yīng)結(jié)果如何。

如何提高IDOR漏洞的危害性

嚴(yán)重性IDOR優(yōu)先

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

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

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

存儲(chǔ)型XSS（Stored-XSS）

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

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