實戰中的越權訪問漏洞

NO.1前言

OWASP發表的 OWASP Top 10 2021

https://owasp.org/Top10/

想必是這個月安全圈較為火熱的新聞話題。看到Broken Access Control 位居榜單首位，可以說這個結果是在情理之中意料之外。

無論是在我日常漏洞審核工作中還是在自身參加的眾測項目中，因鑒權不當產生的漏洞問題越來越多。對于廠商來說，此類問題危害性極大，攻擊者可以突破登錄、身份驗證等手段控制后臺功能或越權到高權限身份，而對于白帽子來說，此類問題較容易挖掘，賞金極高。所以這篇文章我將站在白帽的角度去展開分享 - 實戰中的越權訪問漏洞。

NO.2 繞過訪問控制檢查

案例一

修改 response數據包狀態碼以達到繞過訪問控制檢查，當登錄失敗時，控制身份登錄的狀態碼為 1

通過嘗試后發現當狀態碼 "code":"0" 時，為登錄成功的狀態

總結：此類通過修改狀態碼進行偽造的，我將其分為三類： 

1.后端未作驗證，直接修改狀態碼即可繞過訪問控制檢查。

2. 后端做了驗證，但是會顯示后臺頁面，暴露后臺功能接口，但是沒有數據和權限去操作。 

3. 后端做了校驗，直接回跳到登錄頁面，重新登錄。 

像第二種情況，如果后臺可以去訪問到所以的功能點，可以去交一個低危或中危。

案例二

漏洞詳情

首先我們通過一個任意用戶登錄該系統

在登錄時分析數據包，發現 roleld參數為身份控制參數

當 roleld參數值為 1 時為管理員身份

BurpSuite小Tips，如果每個頁面都需要驗證一次response狀態碼，我們可以在Burp里面進行配置，使其每個response數據包的 boy指定值自動替換

案例三

通過修改參數值以達到越權增刪查改的橫向越權漏洞

漏洞詳情

通過查看預約二維碼捕獲數據包

通過測試發現 id為控制門票二維碼，user_id為身份驗證。由于沒有對身份和對應的門票驗證碼做身份校驗，導致攻擊者可以通過未授權的情況下直接訪問二維碼（將user_id參數刪除，遍歷id即可）

未使用的已付款二維碼

總結：對所以控制身份頁面的數據包要格外關注，尤其在請求數據包中由固定參數去請求資源的情況。

NO.3 未授權訪問后臺功能

由于未對后臺功能鑒權所導致的未授權訪問漏洞 這類漏洞是需要一條攻擊鏈去支撐的，比如：

1.眾測項目甲方給了測試用戶 

2. 通過口令爆破、弱口令登入后臺 

3. 通過源碼審計或JS泄露的路徑去測試后臺功能 

此類漏洞雖然需要前提支撐，但是回報頗大，一般都是成批出現

案例一

首先我們去攔截觸發后臺功能點的數據包，比如增刪查改的數據包

通常是會帶Cookie或token值去進行身份驗證的，此類我們可以刪除Cookie和token值去驗證，刪除后 是否還能觸發功能

發現刪除Cookie后依然可以觸發后臺功能 

再查看該條數據已經不存在

當然，這個除了刪除接口，增加、修改、查看接口都可以進行未授權訪問

案例二

點擊獲取后臺中獎名單接口

發現刪除token依然可以訪問到敏感數據

案例三

通過目錄掃描、FUZZ、猜解等方式獲取到后臺路徑達到未授權訪問后臺功能

1.目錄掃描極力推薦 Dirmap 

https://github.com/H4ckForJob/dirmap

（安裝的時候一定要認真看 README.md的最后面已知缺陷那里，不然有些 PY庫裝不上）

2.FUZZ就是要看字典了，沒什么好說的

3.猜解就要看運氣了

一級目錄為 casServer，通過目錄掃描無果

通過猜解的方式，將 casServer修改為 fileServer，發現存在目錄遍歷，泄露文件上傳點等等

NO.4 API接口未對敏感

HTTP請求方式做鑒權

現在還是有很多站點通過 HTTP請求方式，如 PUT、DELETE去控制站點添加和刪除的功能，但在啟用這 種方式時，若對API接口未作鑒權處理，將引發嚴重危害

案例

將HTTP請求方式修改為 OPTIONS查看允許的 HTTP請求方式，發現存在 DELETE方式

我們修改 HTTP請求方式為 DELETE，刪除站點內現有的數據

首先訪問 XX云，查看現有的文件

我們就選擇這條文件進行刪除

再次訪問發現已經不存在，被刪除掉了

NO.5 總結

在實戰中挖掘越權漏洞，要尤為關注各個功能點對于身份鑒權的方式 

1. 若有注冊功能的系統，注冊兩個賬號，更換為賬號B的 Cookie或 Token去測試賬號 A的功能 

2. 要分析每個參數的功能意義，要多嘗試去修改，比如 flase修改為 true或 success會發生什么 

3. 對后臺的每一個功能數據包去測試，刪除 Cookie或 Token后是否仍能觸發功能效果