IDOR漏洞

• 2019 年 10 月 8 日
• 筆記

什麼是Web/移動應用程序的授權？

Web/移動應用程序的會話管理對終端用戶非常重要。會話管理包括兩個重要部分，即認證和授權。認證部分是「我是誰？」問題的答案，授權部分是「我能做什麼？」問題的答案。

簡而言之，我們會觀察Linux操作系統中write，read和execute文件權限的授權階段。如果用戶想要編寫文件，則必須授予用戶「w」權限，若使用不當，則存在一些隱私侵權行為。

什麼是IDOR漏洞？

應用程序中可能有許多變量，例如「id」，「pid」，「uid」。雖然這些值通常被視為HTTP參數，但它們可以在header和cookie中被找到。攻擊者可以通過更改這些變量的值來訪問，編輯或刪除任何其他用戶的對象。此漏洞稱為IDOR（不安全的直接對象引用）。

首先，它需要了解軟件開發人員開發的應用程序流程。當已登錄的用戶進入Web/移動應用程序時，需要了解所有模塊功能及其子模塊功能。同樣重要的是要記住，此漏洞與安全測試中的XSS，CSRF一樣嚴重，並且是一種通過自動化測試或手動測試檢測不易發現的漏洞。

下圖說明了存在於用戶和服務器之間的IDOR漏洞。

在本文中，將討論以下主題：

• 如何找到可以找到IDOR漏洞的注入點？
• 一些IDOR漏洞提示似乎非常簡單，也是我們遇到的最佳體驗。
• 在測試IDOR漏洞時要考慮的注意事項。
• 如何提供基本授權控制？

有效且快速的IDOR漏洞測試

您可以使用瀏覽器的秘密選項快速地實驗測試IDOR漏洞。因此，當您將常規選項用作普通用戶時，可以將秘密選項用作攻擊者，這將確保您不會註銷。

您可以使用Burp Suite的HTTP歷史記錄選項檢查所有請求。HTTP歷史記錄功能顯示設備（瀏覽器，電話，平板電腦）和應用程序服務器之間的所有流量。此外，您可以使用Burp Suite的範圍功能進行快速測試。因為範圍功能對於創建目標列表非常有用，並且範圍功能允許僅顯示測試範圍的相關數據。

例如， 我們測試的公司「Bugcrowd」，在範圍頁面上範圍僅以「bugcrowd.com」的形式給出。在這種情況下，您可以通過右鍵單擊請求來添加相關範圍。

您可以根據給定的範圍編輯此添加的範圍值，如下所示。

最後，您應該通過選擇「僅顯示範圍內項目」在HTTP歷史記錄選項中執行以下過濾。

這些將幫助您更好地理解應用程序中的readonly，normal，super等角色。

捕獲所有請求

當IDOR漏洞測試時，基本上，你需要執行Web/移動應用程序應創建的所有請求。因為如果你在應用程序中更改了某些內容，則可以使用此案例創建其他請求。如果你有應用程序的所有API請求，如WSDL文件，Swagger頁面等，並且它定期工作，那麼你很幸運，你可以使用它，它將為你提供IDOR測試的便利。

在私有程序中遇到一個例子。在移動應用程序中購買時會添加信用卡。在測試請求之後，可以認為沒有任何漏洞。但是，當進行第二次購買時，會看到信用卡選擇屏幕，此時IDOR漏洞就出現了。當你在此處選擇信用卡時，應用程序將在請求中將信用卡ID發送到服務器，並且該請求提供通路訪問其他用戶的信用卡數據來更改該信用卡ID。

在另一個私有程序中，Web應用程序包括一個應用內消息傳遞系統。用戶可以向其他用戶發送消息並將其他用戶添加到自己的消息中。當用戶嘗試訪問自己的消息之一時，請求轉到「/messages/5955」並且自己的消息ID似乎是「5955」。同樣，當通過向「/messages/5955」發出請求來嘗試訪問另一個用戶的消息時，將不會訪問該消息。當用戶想要將另一個用戶添加到自己的消息時，會出現如下所示的請求。

POST /messages/5955/invite HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0Accept: */*X-Requested-With: XMLHttpRequestCookie: my_cookiesConnection: closeuser=testaccount2  

當檢查此請求時，用戶可以將自己添加到其他用戶的消息並訪問其所有消息。

此外，必須充分了解應用程序中的角色，以便識別IDOR漏洞。如果你知道角色應該做什麼或不應該做什麼，那麼在弱點檢測階段它將非常有用。所以首先，你應該深入了解應用程序！

如何找到注射點

如前所述，您可以使用應用程序的所有功能找到許多IDOR漏洞測試請求。在IDOR漏洞測試中未提供API端點時，.html源代碼或.js文件會很有用。這些文件通常包含有趣的東西和ajax請求，你可以使用這些文件中提出的請求執行IDOR漏洞測試。這可以是應用程序早先提出的請求，也可能是將來可能的請求。

如果幸運的話，你只能看到授權的管理員用戶在javascript文件中看到的請求。因此，源代碼，特別是javascript文件應該好好地進行分析。

此外，你可以在「archive.org」上搜索Web應用程序的舊版本，或許可以在舊的javascript文件中找到有用的請求，或者你也可以使用dorks搜索搜索引擎中的請求。

在某些情況下，id值不是唯一的，如1,2,3,100,1000等，這些id值可以是編碼或散列值。如果你面對編碼值，則可以通過解碼編碼值來測試IDOR漏洞。如果你面對散列值，則應測試散列值是可訪問值還是可預測值。在另一種情況下，您可以在「Referrer」標頭中訪問散列值，因此這些腳本是被可以複製的。

例如，你無法訪問其他用戶的對象，但你可以在對象頁面的源代碼中找到對象的散列ID值，你可以在受害者用戶的應用消息中找到對象的散列id值（這將減少bug的影響）。因此，您可以創建2個測試帳戶作為X和Y，然後在Burp歷史記錄中的Y請求中嘗試X的散列id值。

如果我們觸及另一個主題，某些應用程序的請求可能會嚇到你。例如，包含多個參數的SmartSheet請求似乎過於複雜。

如果你想在此請求中找到注入點，可以使用Burp Suite的比較工具。你需要右鍵單擊該請求，選擇「發送到Comparer」選項。然後，你可以創建使用另一個對象的相同請求並發送到比較工具。

當你訪問比較工具並單擊「單詞」按鈕時，你將看到一個窗口，其中包含更改點。

你可以對HTTP響應使用相同的方法來可以檢查它們的差異。

IDOR錯誤的有趣案例

處理創建請求

某些應用程序在客戶端創建一個id，然後將in create請求發送到服務器。該id值可以是諸如「-1」，「0」或任何其他的數字。現有的id值隨先前創建的對象的id而變化。因此，你可以使用IDOR漏洞刪除或編輯其他用戶的對象。

如果你在創建對象時沒有看到「id」，「user_id」，「value」，「pid」，「post_id」等參數，則應添加並自行測試。你可以通過刪除或編輯應用程序上的任何對象來查找參數關鍵名稱。

盲目的IDOR

在另一種情況下，你可以找到一個IDOR漏洞，但你可能無法實現這一點。例如，如果你在應用程序中更改對象的信息，你將收到包含對象信息的電子郵件。因此，如果你嘗試更改另一個用戶的對象信息，則無法訪問HTTP響應中的任何內容，但你可以使用電子郵件訪問對象的信息。 你可以將其稱之為「Blind IDOR」。

結合他們

IDOR錯誤的影響是可變的，我們會觸及這一點。在某些情況下，IDOR漏洞可以通過觸發無法利用的其他漏洞來幫助你。如果你發現一個不重要的IDOR漏洞，例如編輯用戶非公開和不重要的文件名，並且你想提高您的bug的影響，你可以使用self-XSS漏洞。你在Web應用程序測試時發現的self-XSS漏洞通常是超出範圍並未獲得獎勵的。但是，你可以將self-XSS漏洞與另一個IDOR漏洞結合使用，並且可以將報告提交為「IDOR + Stored XSS」。通過這種方式，你可以實現P2級別的漏洞。

關鍵的IDOR

IDOR漏洞允許我們在某個時間訪問帳戶，而不是編輯或刪除帳戶。這些嚴重錯誤出現在密碼重置，密碼更改，帳戶恢復等方面。首先，你應該仔細檢查電子郵件中的鏈接及其中的參數。然後，你可以捕獲密碼重置請求並使用任何代理工具檢查參數。我們已經多次看到這些請求中的「用戶ID」值，並且我們可以輕鬆地接管到另一個用戶的帳戶。

同時，在請求中發送的標頭值佔用帳戶是一件很重要的事情。可以看出，測試和調試環境中的某些標題值（例如「X-User-ID」，「X-UID」）已更改。這樣用戶就可以像任何用戶一樣行事，並且能夠成功地進行帳戶接管。

HPP漏洞

在極少數情況下，你可以通過在請求中再次添加相同參數來測試IDOR測試的HPP（HTTP參數污染）漏洞。例如：https://www.youtube.com/watch?v=kIVefiDrWUw

創建有效請求

你應該確保發送到服務器的請求是正確的。如果你嘗試向其他用戶發送用戶請求，則必須確保此請求的「CSRF-Token」值有效。因此，你應該將其他用戶的「CSRF-Token」放入請求中。否則，由於令牌值不匹配，你將收到錯誤。這可能會使你被誤導。

同樣，如果您的測試請求是XHR（XML HTTP請求），則必須檢查請求中「Content-Type」標頭參數的驗證。此外，應用程序的請求可能有自定義標頭，如「W-User-Id」，「X-User-Id」，「User-Token」等。如果你想進行正確且完美的測試，則必須發送所有應用中使用的標頭都是正確的。

有用的工具

如前所述，你可以使用Burp Suite功能。此外，你可以使用Burp Suite插件進行IDOR漏洞測試，例如「Authz」，「AuthMatrix」和「Authorize」。

Authz插件用於查看對其他用戶的請求的響應。因此，你可以將X用戶的請求發送給Authz，並嘗試以Y用戶身份訪問它的響應。 此外，你可以為測試IDOR漏洞添加自定義標頭，例如「X-CSRF-Token」。你可以從BApp商店或此地址獲取。

AuthMatrix插件允許你通過在應用程序中為角色註冊cookie值或header值來執行授權檢查。你可以從BApp商店獲取它，如果你想了解更多關於這個插件的信息，請轉到此處。

如果你有API請求，可以使用Wsdler插件用於Burp Suite，SoapUI，Postman等。你可以使用這些工具嘗試所有GET，POST，PUT，DELETE，PATCH請求和成功以及快速的API測試。

IDOR漏洞的影響

IDOR漏洞在Bugcrowd VRT中似乎是「依賴於影響的變種 」，因為它們的影響完全取決於您提交的錯誤。

但是我們根據經驗創建了以下一份關於IDOR漏洞影響的列表。

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

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

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

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

IDOR漏洞的影響取決於項目經理的慎重與否。

如何預防IDOR漏洞？

首先，你應該在創建應用程序時控制所有正常，ajax和API請求。例如，只讀用戶可以在應用程序中寫任何內容嗎？或者非管理員用戶可以訪問並創建僅由admin用戶創建的API令牌嗎？因此，對於所有IDOR漏洞的測試，你都應該像黑客一樣思考。

你可以為所有端點提供應用程序的權限。如果您的「privatesection」端點包含API請求，例如「/api/privatesection/admins」，「/api/privatesection/console」，「/api/privatesection/tokens」，則可以阻止非管理員用戶的端點。

此外，為了使攻擊者的工作更加困難甚至有時甚至可以防止它，您可以使用散列函數並使用散列值而不是正常數字或字符串。

原文鏈接：https://www.bugcrowd.com/how-to-find-idor-insecure-direct-object-reference-vulnerabilities-for-large-bounty-rewards/