您好,登錄后才能下訂單哦!
這篇文章給大家介紹如何用BurpSuite實現越權漏洞IDOR的自動發現識別,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
下面分享一個自動化發現IDOR(越權)漏洞的方法,那就是在BurpSuite中利用Autozie和Autorepeater插件實現IDOR漏洞的探測識別,而無需針對每個請求手動去變化參數或請求。
IDOR(越權)漏洞:也稱“不安全的直接對象引用”,場景發生于當用戶對內部資源的訪問請求,或基于用戶提供的輸入對象進行訪問時,服務端未進行合理的權限驗證,導致當前用戶可以未經授權訪問獲取到不屬于自己賬戶權限的資源或數據。
我們可以在BurpSuite的插件庫Bapp中對Autorize 和 Autorepeater進行安裝:
先來看Autorize,對于客戶端發送的任何請求來說,它會執行一個等效請求,只是其中的Cookies需要是其他用戶的會話Cookie,或是加入其它授權驗證頭,如下我們假設兩個用戶:
用戶A — 管理員
用戶B — 普通用戶
現在,我們用管理員(用戶A)賬戶訪問Web應用,然后在Autorize的請求配置中我們把用戶B的會話Cookie加入,之后,請求將會以用戶B的身份地起。配置如下:
對作用域過濾器中我們稍微做一些設置,以此能直觀地顯示出響應消息,避免收到大量無用結果。接下來,開啟Autorize,對Web應用來說,表面上的訪問客戶端是用戶A,但其實其中用的是用戶B的會話Cookie:
可以看到,在這種情況下,原始長度(Original length)和修正長度(Modified length)之間都沒有任何差異,且響應回來的狀態碼都是200,因此,這樣來看,Web服務端可能存在IDOR漏洞。當然,如果收到的狀態碼是403 Forbidden,那么說明就不存在IDOR漏洞,是不行的。
Autorepeater可以說是復雜版本的Autorize,它可以針對細化參數實現更加準確的測試,如通常涉及到的uuid,、suid、uid等用戶參數。但是,它的設置有些麻煩,比如下面這種uuid的替換測試,需要手動設置:
這種自動化的IDOR探測,在一些云應用中,不僅可針對內部租戶,還能針對跨域租戶進行安全功能審計。比如在下面這里的設置中,我們可以選擇添加替換變量來實現請求主體的變化,另外,還可以對其它參數或請求進行修改,如:
User = Admin
False = True
JSON = XML
關于如何用BurpSuite實現越權漏洞IDOR的自動發現識別就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。