譯：三思之旅

預估稿費：200RMB（不服你也來投稿?。。?/strong>

投稿方式：發送郵件至linwei#360.cn，或登陸網頁版在線投稿

前言

最近在幫合作單位做滲透測試，這是我入行以來第一次參與正式項目。懷著激動而忐忑的心情測了兩周，我一共發現了十幾個漏洞，其中大部分還都是高危漏洞。終于沒有交白卷，忐忑的心情終于放下，現在心里只剩一點小激動，一點成就感。

滲透測試是一個既需要技術，又需要經驗的活兒。思來想去，趁現在興奮勁兒還沒過，趕緊做一下總結，畢竟經驗是通過實戰積累的，而實戰之后的總結則是最好的方式。由于在測試中發現的漏洞以“越權”類居多，而且本人的人生中提交的第一個漏洞也是越權，所以這里就先聊聊越權的那些事兒。

什么是越權

越權（或者說權限提升，Privilege Escalation）是指攻擊者能夠執行他本身沒有資格執行的一些操作，屬于“訪問控制”的問題。用大白話講，越權就是“超越了你你擁有的權限，干了你本來不可能干的事兒”。先來幾個越權的例子：

Winmail普通用戶可直接進入后臺取得域名管理、用戶管理等所有權限

大華DSS平臺低權限賬戶越權直接修改system密碼

前程無憂越權訪問個人簡歷（簡單測試上萬份簡歷可查看）

易企秀越權修改信息致任意用戶登入

一般情況下，常見的訪問控制方式有三種：垂直訪問控制、水平訪問控制和上下文相關的訪問控制。垂直訪問控制允許不同類型的用戶（常見的有基于角色劃分用戶類型）訪問應用程序的不同功能，例如在某系統中普通用戶只能執行有限的操作，管理員則擁有最高權限。水平訪問控制允許用戶訪問一組相同類型的資源，如在一個網銀系統中，每個用戶只能看到他自己的賬戶信息，只能操作自己的賬戶進行轉賬。而上下文相關的訪問控制可確保基于應用程序當前的狀態，限制用戶僅能訪問所允許的內容，如在常見的找回/修改密碼功能中，必須通過身份驗證才能重新設置密碼。許多情況下，垂直訪問控制與水平訪問控制會相交交疊，配合使用。

如果在一個應用中，用戶能夠訪問他本身無權訪問的功能或者資源，就說明該應用存在訪問控制缺陷，也就是說存在越權漏洞。與訪問控制相對應的，將越權分為垂直越權、水平越權和上下文相關的越權。

垂直越權：如果攻擊者能夠執行某項功能，而他所屬的角色并不具備該權限，這就存在垂直越權漏洞，如上述示例中前兩個例子。

水平越權：如果攻擊者能夠執行與自己同級別的其他用戶能夠執行的操作，這就存在水平越權漏洞，如上述示例中的后兩個例子。

上下文相關的越權：如果攻擊者能夠利用應用程序狀態機中的漏洞獲得關鍵資源的訪問權限，這就存在上下文相關的越權。如在找回密碼過程中，攻擊者使用自己的賬戶信息通過驗證，但最終卻通過某種手段（例如使用BurpSuite改數據包）將他人的密碼進行了修改。上下文相關的越權漏洞一般屬于業務邏輯漏洞。

為什么會出現越權

通常情況下，我們使用一個web應用程序提供的功能時，流程是：登錄—>提交請求—>驗證權限—>數據庫查詢—>返回結果。如果在“驗證權限”環節存在缺陷，那么便會導致越權。一種常見的存在越權的情形是：Web應用程序的開發者安全意識不足，認為通過登錄即可驗證用戶的身份，而對用戶登錄之后的操作不做進一步的權限驗證，進而導致越權問題。

1. 通過隱藏URL實現訪問控制

有些應用程序僅通過URL實現訪問控制。例如：使用管理員身份登錄后可以看到后臺管理頁面的鏈接，但是以普通用戶登錄則看不到該鏈接。在這種情況下，開發者認為普通用戶不知道或者很難猜到后臺管理頁面的URL，因此實現對管理功能的保護。這其實是一種錯誤觀點，因為攻擊者完全有可能通過其他方式（如Google Hacking、HTML/js源碼分析、暴力猜解URL、利用其他漏洞等）得到后臺管理URL。

2. 直接對象引用（Direct Object reference）

用戶提交HTTP請求訪問某資源時，被請求資源的標識符常常以GET或者POST請求參數的形式出現在URL查詢字符串或者POST請求主體中提交給服務器。例如，在一個網銀系統中，用戶可以使用以下URL查詢賬戶信息：

其中accountId是用戶自己的賬戶ID。用戶登錄自己的賬戶后，該URL的鏈接會出現在用戶賬戶頁面中，用戶點擊即可跳轉到賬戶信息頁面。雖然其他用戶無法看到這個鏈接，但是如果該網銀系統的訪問控制不完善，攻擊者完全可以通過枚舉accountId進而構造出URL，然后越權查看他人的賬戶信息。

3. 多階段功能

應用程序的一些功能通過幾個階段執行，并且在執行過程中向服務器依次提交多個請求。這種情況很常見，比如轉賬功能、找回密碼功能等，需要先驗證用戶的身份，驗證通過后才允許用戶執行后續動作。多階段功能本身并沒有問題，但是如果開發者認為到達驗證過程后續階段的用戶一定已經擁有了相關的權限，并在后續階段執行操作時不再對用戶提交的請求進行驗證，那么就很有可能存在越權漏洞。攻擊者完全有可能繞過前幾階段的驗證階段，直接執行后續的動作。講一個我在測試中遇到的真實的案例。

某網站在找回密碼時做了很嚴格的驗證，需要驗證姓名、手機號、身份證號等信息，驗證通過了才能修改密碼。那么問題來了，既然做了這么嚴格的驗證，怎么還會存在越權？該網站的“找回密碼”功能被設計成了兩步（提交了兩個請求報文）：第一步驗證用戶身份，這時提交第一個請求報文，驗證成功之后，進入第二步；第二步才是真正的修改密碼的動作，而修改密碼的POST數據包有3個請求參數，分別是新密碼、確認新密碼以及賬號值。問題就出在第二步，在執行修改密碼的動作時，服務器并未驗證被修改密碼的賬戶是否是第一步中通過身份驗證的賬戶，因此攻擊者可以很容易的以自己的身份通過認證，然后修改第二步提交的報文，實現對任意賬戶的密碼修改！

4. 靜態文件

有些Web應用程序在用戶訪問動態頁面時會執行相應的訪問控制檢查，以確定用戶是否擁有執行相關操作所需的權限。但是，用戶仍然會提交對靜態資源的訪問請求，如下載網站中的word、excel、pdf文檔等。這些文檔都是完全靜態的資源，其內容直接由Web服務器返回，它并不在服務器上運行。因此，靜態資源自身并不能執行任何檢查以確認用戶的訪問權限。如果這些靜態資源沒有得到有效的保護，那么任何知曉URL命名規則的人都可以越權訪問這些靜態資源。這種情況的越權也很常見，而且即使不知道URL命名規則，完全有可能通過Google hacking搜索到敏感文件。

5. 平臺配置錯誤

一些應用程序通過在Web服務器或應用程序平臺層使用控件來控制對特定URL路徑的訪問。例如，有些應用程序會根據用戶角色來限制對管理后臺路徑（如/admin）的訪問，如果用戶不屬于“管理員”組，則拒絕其訪問后臺管理頁面的請求。但是，如果在配置平臺及控件時出現錯誤，就可能導致越權訪問。

越權漏洞怎么挖

首先，找出疑似存在越權漏洞的請求。存在越權漏洞的請求有一定的特點，可以從兩個方面下手。

從HTTP請求上來說，就是通過BurpSuite抓取在目標站點正常操作所產生的請求數據包，然后找出可能產生越權的請求。一般情況下，類似上文所述URL的GET或者POST請求都要列為重點懷疑對象：

從業務功能上來說，找到容易產生越權的功能點。常見的越權高發功能點有：根據訂單號查訂單、根據用戶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值配合請求參數值以實現越權攻擊。

總結

實現應用程序的完善的訪問控制不是件容易的事，因此越權漏洞防不勝防。對于開發者而言，一定要有安全意識，時刻保持警惕。以下是幾點建議：

永遠不要相信來自客戶端（用戶）的輸入！

執行關鍵操作前必須驗證用戶身份，多階段功能的每一步都要驗證用戶身份。

對于直接對象引用，加密資源ID，以防止攻擊者對ID進行枚舉。

在前端實現的驗證并不可靠，前端可以驗證用戶的輸入是否合規，在服務器端驗證用戶權限。

參考文獻

黑客攻防技術寶典：Web實戰篇（第2版）

我的越權之道

What is privilege escalation

Direct Object References and Horizontal Privilege Escalation