看我如何通過參數污染繞過IDOR

在一次滲透測試過程中，我偶然間發現了一個有趣的IDOR（不安全的直接對象引用）漏洞，通過使用參數污染技術（利用一個被忽略的測試用例），攻擊者將能夠成功地在目標站點上實現IDOR繞過。

當時，我嘗試在目標應用程序所部屬的REST API中尋找IDOR漏洞，但不幸的是，目標站點中沒有一個節點存在傳統的IDOR漏洞。不過，經過我的一番努力，我發現通過多次提供相同的參數名，並且使用不同的參數值，我們就可以在目標應用上成功實現IDOR繞過了。

接下來，我將跟大家介紹如何使用參數污染技術來實現IDOR繞過。

假設我們的賬號的UserID為123，為了測試IDOR，我們可以將UserID的值從之前的123修改為另一個用戶賬號的UserID-456。如果目標應用程序不存在傳統的IDOR漏洞，那麼我們將會接收到「401 未認證」的狀態提示。

此時，為了實現IDOR繞過，我們需要使用參數污染技術，即傳遞兩個UserID參數，其中一個包含目標賬號的UserID，另一個參數需要包含你賬號的UserID。

下圖顯示的是我們所發送的樣本請求：

在滲透測試的過程中，我也遇到了類似的場景。我的測試目標是一個REST API節點，這個應用程序節點表現出了以下行為：

1、檢測第一個UserID參數； 2、發送請求的用戶需要在GET請求中包含他們的UserID；

在這樣的場景下，我們只需要在原請求的基礎上，增加至兩個UserID參數就可以實現IDOR繞過了。其中的第一個UserID就是目標用戶賬號的UserID，另一個就是攻擊者賬號的UserID，這樣一來，我們就可以欺騙目標應用程序並讓它認為我們所發送的是一個真實的合法請求了。

我賬戶的個人資料會顯示我的全名以及其他相關信息，但這些信息不會顯示給其他的用戶。

我們所構造的惡意請求中需要包含我賬號的UserID，需要注意的是，我在這裡做了大多數滲透測試人員都會做的事情，也就是將請求中的UserID修改為了另一個用戶賬號的UserID。

但不幸的是，啥也沒有發生…而且我還接收到了一個401未授權錯誤，簡直悲劇！

考慮到參數污染技術的實現，我嘗試在測試樣例（請求）中添加了我自己的UserID參數以及目標用戶的UserID，並以此來嘗試訪問目標用戶的個人資料。

想必大家也猜到了，這一次我成功了！

沒錯，通過結合參數污染技術構造出來的惡意請求，我成功拿到了目標用戶的全名以及很多不會公開的敏感信息。不僅如此，由於幾乎目標應用程序的所有參數都無法抵禦這種攻擊，因此這種安全問題將會給這個應用程序帶來「毀滅性」的打擊。

*參考來源：medium，FB小編Alpha_h4ck編譯，轉載請註明來自FreeBuf.COM