風炫安全WEB安全學習第三十八節課 越權漏洞演示與講解

越權漏洞

0x01 漏洞介紹

越權漏洞的危害與影響主要是與對應業務的重要性相關，比如說某一頁面伺服器端響應（不侷限於頁面返回的資訊，有時資訊在響應包中，頁面不一定能看見）中返回登入名、登入密碼、手機號、×××等敏感資訊，如果存在平行越權，通過對使用者ID的遍歷，就可以檢視所有使用者的敏感資訊，這也是一種變相的脫褲，而且很難被防火牆發現，因為這和正常的訪問請求沒有什麼區別，也不會包含特殊字元，具有十足的隱祕性。

水平越權

水平越權指的是攻擊者嘗試訪問與他擁有相同許可權的使用者的資源，怎麼理解呢？比如某系統中有個人資料這個功能，A賬號和B賬號都可以訪問這個功能，但是A賬號的個人資訊和B賬號的個人資訊不同，可以理解為A賬號和B賬號個人資料這個功能上具備水平許可權的劃分。此時，A賬號通過攻擊手段訪問了B賬號的個人資料，這就是水平越權漏洞。

垂直越權

許可權ID不變，許可權型別改變；如普通使用者可使用管理員許可權進行操作。如你登入時，發現cookie中有一個roleID的角色引數，那麼可以通過修改該ID為1或者0，根據具體情況來定，就可以使用管理員許可權了！

0x02 漏洞利用

基於使用者ID的越權

舉個例子：

https://www.xxx.com/user1/userinfo.php?user_id=user1
https://www.xxx.com/user1/userinfo.php?user_id=10001

我們登陸某個系統後，看到某些功能上獲取資訊的方式類似於上鍊接時，可以初步判斷獲取資訊的方式為根據user_id來獲對應的使用者資訊，如果引數為使用者名稱，我們可以手機使用者名稱字典來列舉資訊，根據返回值判斷是否存在問題。當然如果列舉較大，系統使用者數量又不是很多的情況下，可以嘗試註冊新使用者，利用新使用者的使用者名稱來測試是否可以獲取到使用者資訊。

如果引數為一個固定的數字串時，遍歷數字串即可，這種情況下是系統對每個註冊使用者進行了一個使用者id的排序，在眾多的開源CMS上都有使用，當然這個字串也有可能是隨機，如果是隨機的，量不大的情況下可以採用遍歷的形式獲取，量較大可以利用burp的隨機數爆破，或者同樣自己註冊賬戶來測試。

基於功能物件ID的越權

舉個例子：

https://www.xxx.com/user1/userticket.php?user_order=100001
https://www.xxx.com/user1/userticket.php?user_order=49ba59ab

此問題大量存在於使用者訂單、購買、查詢等功能的商家CMS上，例如以上地址，如果user_order是訂單編號，那麼我們可以嘗試遍歷訂單地址來查詢是否存在越權。如果編號並不是單純的訂單數字串，而是類似如上的編碼字串，相信自己的運氣的話可以嘗試某些編碼的情況，例如BASE64、MD5。猜測不到，或者不能明顯的看出來是如果做的處理，註冊新賬號重新下單，會是簡單方便的選擇。

基於未授權訪問的越權

舉個例子：

https://www.xxx.com/user1/[email protected]

在一些系統上登陸使用者後，可以看到類似如上的地址連結，可能你會覺得這個跟問題1類似，但是也有可能多一張問題情況，在非登陸的情況下仍然可以訪問到詳細資訊。如果可以，則證明後端對身份的效驗只是基於引數user，並沒有效驗使用者的session是否已登陸。此問題曾發現於一個系統後端支付訂單複核的功能中，問題可想而知。

基於功能地址的越權

舉個例子：

https://www.xxx.com/user/getuserinfo.php

如上地址，正常情況下，只訪問此後臺地址時，一般會跳轉到登陸地址，或者登陸後用來檢視某個具體的功能，獲取資料的情況根據訪問的連結地址來，理論上此功能並不存在越權可能，因為沒有我們可以修改的引數。但是對許可權及功能的限制可能只侷限於使用者選單的限制，根據常用連結，可以猜測是否存在以下地址：

/getuserorder.php
/adduser.php
/deluser.php
/getalluser.php
/todetailpage.php
/ordercreate.php......

因為在絕大部分系統中，開發為了方便區別功能和頁面，通常會利用對應的英文來命名檔案，但這些檔案並不是任意使用者都可以訪問到的，所以可以猜測訪問地址是否英文的拼接來猜測路徑。對於此問題的快捷測試是獲取一個高許可權賬號，當然對於未授權測試來說，很難實現。

基於介面身份的越權

https://www.xxx.com/user/userinfo.php
post: 
{'userid':'10001','username':'name','userage':'18','usermobile':'18080808888'}

例如如上介面，修改使用者資訊，當我們點選某個系統的修改自身資料時，會發送一個類似的json資料包，其中userid對應我們自己的使用者id，修改後，可以修改對應id的使用者資料。修改方式類似問題1。區別在於一個頁面可見，一個頁面不直觀可見，一個查詢，一個修改。需要配合其他越權查詢漏洞，或者賬號來識別是否修改成功。

0x03 如何修復

建議做一個過濾器，對許可權進行全域性校驗（每次呼叫某個介面時，可先對許可權進行校驗）。大體流程是：第一步清洗URL地址，並提取Api介面名稱；第二步從session中提取當前登入使用者的userid；第三步提取當前使用者的角色id；第四步判斷當前使用者對應的角色是否有許可權訪問當前Api介面（檢查垂直越權）；最後判斷當前登入使用者是否對目標物件有操作許可權（檢查水平越權）。

推薦使用JWT 驗證

參考：
http://blog.evalshell.com/2020/12/23/風炫安全web安全學習第三十八節課-越權漏洞演示與/