破壞的物件級授權

---

什麼是破壞的物件級授權？

破壞的物件級授權 (BOLA) 也稱為不安全的直接物件引用 (IDOR)。此問題發生在伺服器未正確驗證當前授權使用者或未授權使用者是否正在訪問資料以讀取、更新或刪除他們無權訪問的物件時。

破壞的物件級授權 (BOLA) 型別

主要有兩種型別的 BOLA。如果將使用者 ID 或物件 ID 傳遞給伺服器，則可以執行這些操作，我們將研究這兩種情況。

基於使用者 ID

如果使用者 ID 以清晰可見的方式（例如在 URL 或請求中）傳遞給伺服器，例如，當我們請求訪問特定使用者的全部資源時：

<https://google.com/get_users_search_history?userID=1234>

檢視上面的 URL 後，如果我們將使用者 ID 更改為其他使用者的使用者 ID，則我們無權獲取其他使用者的搜尋歷史記錄，但如果端點容易受到破壞的物件級授權問題的影響，則我們可以檢視其他使用者的搜尋歷史記錄。

基於物件 ID

此型別的漏洞也可能存在，因為物件 ID 在伺服器未正確驗證使用者是否有權訪問該物件時會傳遞給伺服器。例如，當開發人員需要實現安全功能來保護某些資源而又不保護某些資源時。他們可能會避免或忘記保護某些應該受到保護的物件。

利用破壞的物件級訪問漏洞

一旦發現此漏洞，就很容易利用它。攻擊者只需修改請求中的識別符號，他們就可以被授權訪問他們不應該被允許訪問的物件。

讓我們用一個例子來討論一下。

在這裡，我們有一個用於呼叫 API 的 URL：

https://myemail.com/messages/12345

此 API 呼叫用於獲取使用者的私人訊息。正在使用的資源是訊息。訊息是我們指的破壞的物件級授權的物件，我們假設訊息只能由預期接收者訪問和讀取。

在 API 呼叫中，我們有訊息的 ID **12345**。對於攻擊者來說，這是一個重要的引數。該 ID 告訴服務要返回哪個記錄。API 從資料儲存中提取該記錄並在響應中返回它。

現在讓我們看看如果我們將 ID 從 **12345** 更改為 **12346** 會發生什麼？

**示例**：

https://myemail.com/messages/12346

如果 ID 為 12346 的訊息是為我們的使用者準備的，我們應該能夠獲取它。但如果該訊息屬於其他使用者，則 API 永遠不應該返回它。如果我們設法檢索到該訊息，那麼我們就發生了破壞級別物件授權故障。

另一個例子是傳遞 POST 請求來更新資源。我們可以在 JSON 負載中使用 ID：

{
   "userId": "12345678",
   "oldPassword": "My_0ld_Pa$$",
   "newPassword": "$uperS3CurE"
}

如果我們能夠在請求中放入任何 userId 並能夠更新其他使用者資訊，那麼我們就會遇到一個大問題。

技術影響

一旦我們找到漏洞，就可以透過不同的方式利用它。我們可以在 API 上使用不同的 HTTP 方法。我們可以使用該輸入引數或 ID 來更新甚至刪除訊息！

如果我們能夠破壞所有 ID 並能夠刪除所有儲存的訊息會發生什麼？這是一個很大的影響。