本文中提供的例子均來自網絡已公開測試的例子，僅供參考。

　　本期鬥哥帶來越權漏洞和大家探討探討。什麼是越權呢？

　　越權，顧名思義，就是超出了權限或權力範圍。多數WEB應用都具備權限劃分和控制，但是如果權限控制功能設計存在缺陷，那麼攻擊者就可以通過這些缺陷來訪問未經授權的功能或數據，這就是我們通常說的越權漏洞。攻擊者越權後就可以進行一些操作，例如查看敏感信息、進行一些增刪改查的操作等等。

　　我們一般將越權漏洞分爲三種：水平越權、垂直越權和權限框架缺陷。以下是越權漏洞的幾種攻擊場景。

　　水平越權

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

　　系統中所有具備水平權限劃分的功能，都存在水平越權的風險，以下是常出現的水平越權的功能的幾種場景：

　　1. 基於用戶身份ID

　　在使用某個功能時通過用戶提交的身份ID（用戶ID、賬號、手機號、證件號等用戶唯一標識）來訪問或操作對應的數據。

　　舉個栗子：

　　①某航空公司存在水平越權漏洞，提交訂單後抓取數據包。

　　②可以發現請求中有蠻多ID信息，通常情況下，我們一般會挨個測試，是否存在越權漏洞，其中passenger1d1是乘機人，contactId聯繫人。

　　③經測試可發現這兩個參數修改後，可查看到其他乘機人的身份證及聯繫人信息。

　　2. 基於對象ID

　　在使用某個功能時通過用戶提交的對象ID（如訂單號、記錄號）來訪問或操作對應的數據。

　　舉個栗子：

　　①某系統存在水平越權漏洞。

　　②抓取訂單提交的數據包，發現有一個oid很可疑。

　　③嘗試進行測試發現，可遍歷訂單號，查看他人待付款訂單信息。

　　3.基於文件名

　　在使用某個功能時通過文件名直接訪問文件，最常見於用戶上傳文件的場景。

　　舉個栗子：

　　②遍歷fileid可以下載到數十萬的資質文件：

　　http://**.**.**.**/sFile-image.action?fileid=9316

　　http://**.**.**.**/sFile-image.action?fileid=39316

　　垂直越權

　　垂直越權指的是一個低級別攻擊者嘗試訪問高級別用戶的資源。比如說某個系統分爲普通用戶和管理員，管理員有系統管理功能，而普通用戶沒有，那我們就可以理解管理功能具備垂直權限劃分，如果普通用戶能利用某種攻擊手段訪問到管理功能，那我們就稱之爲垂直越權。

　　垂直越權主要以下兩種攻擊場景：

　　1.未認證賬戶訪問無需認證後能訪問該功能。

　　舉個栗子：

　　①某站點後臺僅使用js跳轉來限制未授權的用戶訪問。

　　②去掉js可以成功訪問後臺，且可以進行操作。

　　2. 不具備某個功能權限的賬戶認證後成功訪問該功能。

　　舉個栗子：

　　①使用default用戶名和密碼：useradmin / admin!@#$%^登錄系統。

　　②成功登錄後臺。

　　③依次點擊“對象管理——>用戶管理——>編輯‘useradmin’——>得到URL：*.*.*.*/cgi-bin/webif/Objset-users.sh?edituser=edituser&id=5”

　　④修改參數id爲：id=4，成功垂直越權telecomadmin。

　　⑤查看源碼，可讀取telecomadmin密碼：telecomadmin34224223，至此已獲得最高管理員權限，可以完全對該設備進行操作。

　　⑥由下圖可判斷出telecomadmini爲高權限用戶。

　　權限框架缺陷

　　權限控制框架是實現權限控制功能的基礎，如果權限控制框架本身存在缺陷容易被攻陷會導致權限控制功能完全失效。在cookie中使用簡單的權限標識來標記用戶的權限等級或使用用戶請求參數中所帶的簡單用戶ID來控制用戶權限，是典型的權限框架缺陷。

　　舉個栗子：

　　①某系統存在弱口令：guest、guest，訪問http://**.**.**.**/nbr.htm，然後登進去 只能看到系統首頁和流量監控。

　　②然後用cookie修改工具，先登錄guest賬號。

　　③然後修改cookie信息，user=guest 改成user=admin 重要的是需要後面刪掉分號。

　　④然後刷新。

　　⑤admin賬號擁有更多的功能，可以修改管理員密碼等。

　　修復意見

　　好啦，上面就是鬥哥近期整理的一點越權漏洞栗子，越權漏洞可大可小，那我們要怎麼控制呢？

　　1.採用成熟的權限管理框架，如spring security。

　　2.用戶進行訪問操作的憑證（如用戶ID、產品號碼、訂單流水號等）優先採用在服務端關聯session或加密後放在session中的方式獲取。

　　3.必須採用表單或其他參數提交用戶進行訪問操作的憑證（如用戶ID、產品號碼、訂單流水號等）時，應儘可能採用難以猜測的構造方式（增加字母及隨機數字等）或採用複雜的加密算法加密後提交，應對客戶端提交的憑證與會話的權限進行嚴格的驗證，如提交的產品號碼是否爲隸屬於登錄用戶的產品號碼。

　　4.對管理功能模塊進行嚴格的權限驗證，如非必要建議不對互聯網開放或進行網絡層的訪問控制。

　　專欄