一、簡述
越權漏洞是比較常見的漏洞類型，越權漏洞可以理解爲，一個正常的用戶A通常只能夠對自己的一些信息進行增刪改查，但是由於程序員的一時疏忽，對信息進行增刪改查的時候沒有進行一個判斷，判斷所需要操作的信息是否屬於對應的用戶，可以導致用戶A可以操作其他人的信息。也可以：越權漏洞是一種很常見的邏輯安全漏洞。可以這樣理解：服務器端對客戶提出的數據操作請求過分信任，忽略了對該用戶操作權限的判定，導致攻擊賬號擁有了其他賬戶的增刪改查功能。
二、越權分類
一般情況下，常見的訪問控制方式有三種：垂直訪問控制、水平訪問控制和上下文相關的訪問控制。垂直訪問控制允許不同類型的用戶（常見的有基於角色劃分用戶類型）訪問應用程序的不同功能，例如在某系統中普通用戶只能執行有限的操作，管理員則擁有最高權限。水平訪問控制允許用戶訪問一組相同類型的資源，如在一個網銀系統中，每個用戶只能看到他自己的賬戶信息，只能操作自己的賬戶進行轉賬。而上下文相關的訪問控制可確保基於應用程序當前的狀態，限制用戶僅能訪問所允許的內容，如在常見的找回/修改密碼功能中，必須通過身份驗證才能重新設置密碼。許多情況下，垂直訪問控制與水平訪問控制會相交交疊，配合使用。如果在一個應用中，用戶能夠訪問他本身無權訪問的功能或者資源，就說明該應用存在訪問控制缺陷，也就是說存在越權漏洞。與訪問控制相對應的，將越權分爲垂直越權、水平越權和上下文相關的越權。
垂直越權
如果攻擊者能夠執行某項功能，而他所屬的角色並不具備該權限，這就存在垂直越權漏洞，
水平越權
如果攻擊者能夠執行與自己同級別的其他用戶能夠執行的操作，這就存在水平越權漏洞
交叉越權（上下文相關）
如果攻擊者能夠利用應用程序狀態機中的漏洞獲得關鍵資源的訪問權限，這就存在上下文相關的越權
三、產生原因
通常情況下，我們使用一個web應用程序提供的功能時，流程是：登錄—>提交請求—>驗證權限—>數據庫查詢—>返回結果。如果在“驗證權限”環節存在缺陷，那麼便會導致越權。一種常見的存在越權的情形是：Web應用程序的開發者安全意識不足，認爲通過登錄即可驗證用戶的身份，而對用戶登錄之後的操作不做進一步的權限驗證，進而導致越權問題。
通過隱藏URL實現訪問控制
有些應用程序僅通過URL實現訪問控制。例如：使用管理員身份登錄後可以看到後臺管理頁面的鏈接，但是以普通用戶登錄則看不到該鏈接。在這種情況下，開發者認爲普通用戶不知道或者很難猜到後臺管理頁面的URL，因此實現對管理功能的保護。這其實是一種錯誤觀點，因爲攻擊者完全有可能通過其他方式（如Google Hacking、HTML/js源碼分析、暴力猜解URL、利用其他漏洞等）得到後臺管理URL。
直接對象引用（Direct Object reference）
用戶提交HTTP請求訪問某資源時，被請求資源的標識符常常以GET或者POST請求參數的形式出現在URL查詢字符串或者POST請求主體中提交給服務器。例如，在一個網銀系統中，用戶可以使用以下URL查詢賬戶信息：1https://www.onlinebank.com/viewInfo.php?accountId=12345678
其中accountId是用戶自己的賬戶ID。用戶登錄自己的賬戶後，該URL的鏈接會出現在用戶賬戶頁面中，用戶點擊即可跳轉到賬戶信息頁面。雖然其他用戶無法看到這個鏈接，但是如果該網銀系統的訪問控制不完善，攻擊者完全可以通過枚舉accountId進而構造出URL，然後越權查看他人的賬戶信息。
靜態文件
有些Web應用程序在用戶訪問動態頁面時會執行相應的訪問控制檢查，以確定用戶是否擁有執行相關操作所需的權限。但是，用戶仍然會提交對靜態資源的訪問請求，如下載網站中的word、excel、pdf文檔等。這些文檔都是完全靜態的資源，其內容直接由Web服務器返回，它並不在服務器上運行。因此，靜態資源自身並不能執行任何檢查以確認用戶的訪問權限。如果這些靜態資源沒有得到有效的保護，那麼任何知曉URL命名規則的人都可以越權訪問這些靜態資源。這種情況的越權也很常見，而且即使不知道URL命名規則，完全有可能通過Google hacking搜索到敏感文件。
平臺配置錯誤
一些應用程序通過在Web服務器或應用程序平臺層使用控件來控制對特定URL路徑的訪問。例如，有些應用程序會根據用戶角色來限制對管理後臺路徑（如/admin）的訪問，如果用戶不屬於“管理員”組，則拒絕其訪問後臺管理頁面的請求。但是，如果在配置平臺及控件時出現錯誤，就可能導致越權訪問。
四、如何挖掘越權漏洞
首先，找出疑似存在越權漏洞的請求。存在越權漏洞的請求有一定的特點，可以從兩個方面下手。從HTTP請求上來說，就是通過BurpSuite抓取在目標站點正常操作所產生的請求數據包，然後找出可能產生越權的請求。一般情況下，類似上文所述URL的GET或者POST請求都要列爲重點懷疑對象：
1https://www.onlinebank.co/viewInfo.php?accountId=12345678，從業務功能上來說，找到容易產生越權的功能點。
這時，需要兩個不同的賬號（下文分別稱爲賬號A和賬號B），以便測試登錄賬號A後進行操作能否影響到賬號B。注意在瀏覽器中測試時，需要使用兩個瀏覽器分別登錄不同的賬號，或者使用瀏覽器的隱私瀏覽功能登錄其中一個賬號。以上文提到的URL爲例進行說明。假設賬號A的id爲1234，賬號B的id爲5678，BurpSuite中抓取的數據包都是在賬號A的。我的習慣做法是：在BurpSuite中將該請求發送到Repeater，然後將參數id的值修改爲5678，最後提交修改後的請求包；服務器返回響應後，可以看一下BurpSuite中收到的響應報文。如果響應報文直接提示錯誤之類的，基本上可以確定此處不存在越權；如果響應報文提示操作成功，此時應該使用瀏覽器登錄賬號B進行二次確認，如果數據確實有相應的改動，那麼則說明這裏存在越權漏洞。
這裏需要注意：BurpSuite中報文提示操作成功有可能是誤報，必須在瀏覽器中進行再次確認。而對於查詢訂單這類的請求來說，情況更簡單了，修改參數id提交請求，如果返回了賬號B的數據，那麼就可以確定存在越權。當然，越權漏洞的攻擊點不僅僅存在於請求參數中，還有可能在Cookie中。因此，需要具體情況具體分析，複雜一點的可能還需要Cookie值配合請求參數值以實現越權攻擊。
實例
白帽子 路人甲：幫朋友挑選一款汽車時，登錄了某品牌的官網，無意中看到了旗下的招聘系統網址，http://rec****.***.cn/re****t***t/resume/addresume/person_id/161101/lid/1/job_id/1，這個網址就比較有趣了，person_id代表的是應聘用戶的賬號，161101意味着用戶數量超過16萬，如果存在越權漏洞，那麼修改一次161101這個數據，就可以看到一個用戶的應聘數據。經過測試還真的是這樣。
漏洞標題： 同花順某處鑑權可被遍歷導致用戶信息泄露
詳細說明：http://cats.10jqka.com.cn/catreqtype=cs_query_func_list&userid=11122233&cf_id=203&resp=xml&encoding=gbk&Cfg_id=1&showorder=1
userid 可以任意遍歷，cf_id 產品id 也可以任意遍歷
userid 任意修改，就能查詢任意用戶的購買產品信息
非原創
參考文獻
[https://xianzhi.aliyun.com/forum/read/313.html]
[https://www.secpulse.com/archives/54137.html]