專業理論深解：

基本原則－預設拒絕 (Deny-by-Default)： 存取控制的核心設計原則是，除非被明確授予權限，否則所有請求都應被拒絕。檢查必須在伺服器端強制執行，不能依賴客戶端隱藏或禁用功能。

垂直權限提升 (Vertical Privilege Escalation)： 一個低權限用戶（如普通用戶）成功執行了高權限用戶（如管理員）才能執行的功能。

攻擊方法： 普通用戶登入後，直接猜測並瀏覽管理員功能的路徑（如 /admin/dashboard）。如果後端沒有對每個請求進行權限校驗，攻擊就會成功。

水平權限提升 (Horizontal Privilege Escalation)： 一個用戶成功訪問了屬於另一個同級別用戶的資源。這通常表現為 不安全的直接物件引用 (IDOR - Insecure Direct Object References)。

攻擊方法： 在一個請求中，我發現了直接引用資源的參數，如 GET /api/orders?id=101。我會嘗試將 id 修改為 102，看是否能獲取到屬於其他用戶的訂單數據。IDOR 也可能出現在 Cookie、請求體或隱藏表單欄位中。

基於功能的存取控制失效： 應用程式可能在用戶介面上根據角色隱藏了特定按鈕或連結，但並未在後端對應的 API 端點上實施相應的權限檢查。攻擊者可以直接呼叫這些 API。

防禦模型： 現代應用常採用基於角色的存取控制 (RBAC - Role-Based Access Control) 或基於屬性的存取控制 (ABAC - Attribute-Based Access Control) 模型，在程式碼的統一層（如中介軟體、攔截器）進行集中式的權限校驗。

這與我的 Burp Suite / DVWA 實戰連結： 這是我需要系統性測試的領域。我會用一個低權限帳號登入，完整爬取網站功能，然後在 Burp 的站點地圖 (Site map) 中，將所有請求發送到 Repeater。接著，我會換上高權限帳號的 Cookie，重放這些請求，觀察是否有之前被拒絕的請求現在成功了。Burp 的 AuthMatrix 和 Authorize 擴充功能可以極大地自動化這個流程。

在一個 RESTful API 設計中，如何系統性地測試其所有端點 (GET, POST, PUT, DELETE) 是否存在存取控制漏洞？

關鍵攻擊向量與場景剖析

1. 不安全的直接物件引用 (IDOR - Insecure Direct Object References)
   這是最典型的水平權限提升，也是滲透測試中最常見的漏洞之一。

場景： 應用程式在引用數據時，使用了可預測的、直接來自資料庫的識別碼，並且在處理請求時沒有驗證當前用戶是否有權操作該識別碼。

攻擊向量的藏身之處：

URL 查詢參數： GET /user/orders?order_id=1001

URL 路徑： GET /api/v1/users/502/profile

POST 請求主體： { "userId": "205", "action": "update" }

隱藏的表單欄位：

Cookies: Cookie: user_id=405

攻擊手法： 攻擊者只需登入自己的帳號，找到這些直接引用，然後系統性地修改 ID（例如，將 1001 改為 1002, 1003...），就能非法遍歷和存取屬於其他用戶的數據。

2. 功能級別的存取控制缺失 (Missing Function-Level Access Control)
   這是最典型的垂直權限提升。

場景： 開發者錯誤地認為，只要不在前端 UI 上為普通用戶顯示管理員功能的按鈕或連結，就足夠安全了。但他們忽略了，攻擊者可以不透過 UI，直接構造 HTTP 請求來呼叫後端的管理 API。

攻擊手法：

攻擊者以普通用戶身份登入。

透過猜測、爬取 JavaScript 檔案或使用管理員帳號（如果有的話）來獲取管理功能的 URL 路徑，例如 /admin/deleteUser?id=123。

攻擊者在保持普通用戶登入狀態的情況下，直接向這個 URL 發送請求。

如果後端 API 在執行 deleteUser 這個敏感操作前，沒有再次驗證當前用戶的會話是否具有「管理員」角色，那麼攻擊就會成功。

3. HTTP 方法權限配置不當 (Verb Tampering)
   場景： 一個 API 端點可能對不同的 HTTP 方法 (GET, POST, PUT, DELETE) 設置了不同的權限。例如，所有用戶都可以 GET 一篇文章，但只有作者或管理員才能 DELETE 它。開發者可能只保護了其中幾個方法，而忽略了其他的。

攻擊手法： 攻擊者發現他可以透過 GET /api/posts/123 查看文章。他會嘗試用同樣的 session cookie，發送 DELETE /api/posts/123 請求。如果後端忘記為 DELETE 方法加上權限檢查，文章就會被非法刪除。