1、什麼是越權？
越權（或者說權限提升，Privilege Escalation）是指攻擊者能夠執行他本身沒有資格執行的一些操作，屬於“訪問控制”的問題。用大白話講，越權就是“超越了你你擁有的權限，幹了你本來不可能幹的事兒”。先來幾個越權的例子：
Winmail普通用戶可直接進入後臺取得域名管理、用戶管理等所有權限
一般情況下，常見的訪問控制方式有三種：垂直訪問控制、水平訪問控制和上下文相關的訪問控制。垂直訪問控制允許不同類型的用戶（常見的有基於角色劃分用戶類型）訪問應用程序的不同功能，例如在某系統中普通用戶只能執行有限的操作，管理員則擁有最高權限。水平訪問控制允許用戶訪問一組相同類型的資源，如在一個網銀系統中，每個用戶只能看到他自己的賬戶信息，只能操作自己的賬戶進行轉賬。而上下文相關的訪問控制可確保基於應用程序當前的狀態，限制用戶僅能訪問所允許的內容，如在常見的找回/修改密碼功能中，必須通過身份驗證才能重新設置密碼。許多情況下，垂直訪問控制與水平訪問控制會相交交疊，配合使用。
如果在一個應用中，用戶能夠訪問他本身無權訪問的功能或者資源，就說明該應用存在訪問控制缺陷，也就是說存在越權漏洞。與訪問控制相對應的，將越權分爲垂直越權、水平越權和上下文相關的越權。
垂直越權：如果攻擊者能夠執行某項功能，而他所屬的角色並不具備該權限，這就存在垂直越權漏洞，如上述示例中前兩個例子。
水平越權：如果攻擊者能夠執行與自己同級別的其他用戶能夠執行的操作，這就存在水平越權漏洞，如上述示例中的後兩個例子。
上下文相關的越權：如果攻擊者能夠利用應用程序狀態機中的漏洞獲得關鍵資源的訪問權限，這就存在上下文相關的越權。如在找回密碼過程中，攻擊者使用自己的賬戶信息通過驗證，但最終卻通過某種手段（例如使用BurpSuite改數據包）將他人的密碼進行了修改。上下文相關的越權漏洞一般屬於業務邏輯漏洞。
2、爲什麼會出現越權
通常情況下，我們使用一個web應用程序提供的功能時，流程是：登錄—>提交請求—>驗證權限—>數據庫查詢—>返回結果。如果在“驗證權限”環節存在缺陷，那麼便會導致越權。一種常見的存在越權的情形是：Web應用程序的開發者安全意識不足，認爲通過登錄即可驗證用戶的身份，而對用戶登錄之後的操作不做進一步的權限驗證，進而導致越權問題。
2.1、 通過隱藏URL實現訪問控制
有些應用程序僅通過URL實現訪問控制。例如：使用管理員身份登錄後可以看到後臺管理頁面的鏈接，但是以普通用戶登錄則看不到該鏈接。在這種情況下，開發者認爲普通用戶不知道或者很難猜到後臺管理頁面的URL，因此實現對管理功能的保護。這其實是一種錯誤觀點，因爲攻擊者完全有可能通過其他方式（如Google Hacking、HTML/js源碼分析、暴力猜解URL、利用其他漏洞等）得到後臺管理URL。
2.2、 直接對象引用（Direct Object reference）
用戶提交HTTP請求訪問某資源時，被請求資源的標識符常常以GET或者POST請求參數的形式出現在URL查詢字符串或者POST請求主體中提交給服務器。例如，在一個網銀系統中，用戶可以使用以下URL查詢賬戶信息：
https://www.onlinebank.com/viewInfo.php?accountId=12345678
其中accountId是用戶自己的賬戶ID。用戶登錄自己的賬戶後，該URL的鏈接會出現在用戶賬戶頁面中，用戶點擊即可跳轉到賬戶信息頁面。雖然其他用戶無法看到這個鏈接，但是如果該網銀系統的訪問控制不完善，攻擊者完全可以通過枚舉accountId進而構造出URL，然後越權查看他人的賬戶信息。
2.3、 多階段功能
應用程序的一些功能通過幾個階段執行，並且在執行過程中向服務器依次提交多個請求。這種情況很常見，比如轉賬功能、找回密碼功能等，需要先驗證用戶的身份，驗證通過後才允許用戶執行後續動作。多階段功能本身並沒有問題，但是如果開發者認爲到達驗證過程後續階段的用戶一定已經擁有了相關的權限，並在後續階段執行操作時不再對用戶提交的請求進行驗證，那麼就很有可能存在越權漏洞。攻擊者完全有可能繞過前幾階段的驗證階段，直接執行後續的動作。講一個我在測試中遇到的真實的案例。
某網站在找回密碼時做了很嚴格的驗證，需要驗證姓名、手機號、身份證號等信息，驗證通過了才能修改密碼。那麼問題來了，既然做了這麼嚴格的驗證，怎麼還會存在越權？該網站的“找回密碼”功能被設計成了兩步（提交了兩個請求報文）：第一步驗證用戶身份，這時提交第一個請求報文，驗證成功之後，進入第二步；第二步纔是真正的修改密碼的動作，而修改密碼的POST數據包有3個請求參數，分別是新密碼、確認新密碼以及賬號值。問題就出在第二步，在執行修改密碼的動作時，服務器並未驗證被修改密碼的賬戶是否是第一步中通過身份驗證的賬戶，因此攻擊者可以很容易的以自己的身份通過認證，然後修改第二步提交的報文，實現對任意賬戶的密碼修改！
2.4、 靜態文件
有些Web應用程序在用戶訪問動態頁面時會執行相應的訪問控制檢查，以確定用戶是否擁有執行相關操作所需的權限。但是，用戶仍然會提交對靜態資源的訪問請求，如下載網站中的word、excel、pdf文檔等。這些文檔都是完全靜態的資源，其內容直接由Web服務器返回，它並不在服務器上運行。因此，靜態資源自身並不能執行任何檢查以確認用戶的訪問權限。如果這些靜態資源沒有得到有效的保護，那麼任何知曉URL命名規則的人都可以越權訪問這些靜態資源。這種情況的越權也很常見，而且即使不知道URL命名規則，完全有可能通過Google hacking搜索到敏感文件。
2.5、 平臺配置錯誤
一些應用程序通過在Web服務器或應用程序平臺層使用控件來控制對特定URL路徑的訪問。例如，有些應用程序會根據用戶角色來限制對管理後臺路徑（如/admin）的訪問，如果用戶不屬於“管理員”組，則拒絕其訪問後臺管理頁面的請求。但是，如果在配置平臺及控件時出現錯誤，就可能導致越權訪問。
3、越權漏洞怎麼挖
首先，找出疑似存在越權漏洞的請求。存在越權漏洞的請求有一定的特點，可以從兩個方面下手。
從HTTP請求上來說，就是通過BurpSuite抓取在目標站點正常操作所產生的請求數據包，然後找出可能產生越權的請求。一般情況下，類似上文所述URL的GET或者POST請求都要列爲重點懷疑對象：
https://www.onlinebank.com/viewInfo.php?accountId=12345678
從業務功能上來說，找到容易產生越權的功能點。常見的越權高發功能點有：根據訂單號查訂單、根據用戶ID查看帳戶信息、修改/找回密碼等。
確定了懷疑對象之後，還需要進一步的分析，以確定是否真的存在越權。這時，需要兩個不同的賬號（下文分別稱爲賬號A和賬號B），以便測試登錄賬號A後進行操作能否影響到賬號B。注意在瀏覽器中測試時，需要使用兩個瀏覽器分別登錄不同的賬號，或者使用瀏覽器的隱私瀏覽功能登錄其中一個賬號。
以上文提到的URL爲例進行說明。假設賬號A的id爲1234，賬號B的id爲5678，BurpSuite中抓取的數據包都是在賬號A的。我的習慣做法是：在BurpSuite中將該請求發送到Repeater，然後將參數id的值修改爲5678，最後提交修改後的請求包；服務器返回響應後，可以看一下BurpSuite中收到的響應報文。如果響應報文直接提示錯誤之類的，基本上可以確定此處不存在越權；如果響應報文提示操作成功，此時應該使用瀏覽器登錄賬號B進行二次確認，如果數據確實有相應的改動，那麼則說明這裏存在越權漏洞。這裏需要注意：BurpSuite中報文提示操作成功有可能是誤報，必須在瀏覽器中進行再次確認。而對於查詢訂單這類的請求來說，情況更簡單了，修改參數id提交請求，如果返回了賬號B的數據，那麼就可以確定存在越權。
當然，越權漏洞的攻擊點不僅僅存在於請求參數中，還有可能在Cookie中。因此，需要具體情況具體分析，複雜一點的可能還需要Cookie值配合請求參數值以實現越權攻擊。
4、總結
實現應用程序的完善的訪問控制不是件容易的事，因此越權漏洞防不勝防。對於開發者而言，一定要有安全意識，時刻保持警惕。以下是幾點建議：
永遠不要相信來自客戶端（用戶）的輸入！
執行關鍵操作前必須驗證用戶身份，多階段功能的每一步都要驗證用戶身份。
對於直接對象引用，加密資源ID，以防止攻擊者對ID進行枚舉。
在前端實現的驗證並不可靠，前端可以驗證用戶的輸入是否合規，在服務器端驗證用戶權限。
5、友情補充
一、局部縱向越權解決方案：
把這種越權問題，作爲整塊測試任務來做。新建自動化測試Case，讓每一個接口（尤其是涉及分級的接口）都要有多個不同級別的用戶進行權限校驗。根據斷言和數據庫一致性（必須，有時候接口返回的成功，並不一定是成功），來判斷是否存在越權問題。
操作流程如下：
1、添加最高級別用戶S的測試Case
2、添加普通用戶A的自動化測試Case
3、添加低級別用戶B的自動化測試Case
4、多用戶統一訪問僅開放給S級別用戶接口。Case通過條件：A、B訪問失敗
5、S、A、B循環第四步
二、橫向越權解決方案：
搭建一個橫向越權mock數據系統。
1、輸入爲：接口url ,以及正常的json 串。
2、處理過程：對url和json串進行比對，找到兩者相同字段。
3、系統修改一致字段對應value
4、輸出一組或者幾組測試數據
5、將mock出來的數據，進行自動化測試。
6、驗證是否存在橫向越權。
6、參考文獻
Direct Object References and Horizontal Privilege Escalation
越權問題解決優化方案
【技術分享】聊聊越權那些事兒