Pen Testing for Beginners | Complete Step-by-Step Tutorial (2026)
三句話摘要
以 Burp Suite 對 OWASP Juice Shop 進行 Web 滲透測試，實際示範 IDOR 漏洞的發現、驗證與報告撰寫流程。 --- IDOR 漏洞的根本原因是伺服器端缺乏逐次授權驗證，只要能修改 URL 中的物件 ID 就能橫向存取他人資料，而 Burp Suite 的 Repeater 與 Intruder 是快速發現並批量驗證此類漏洞的最直接手段。 滲透測試的目的是找漏洞、給修補，而非破壞系統。 真實場景中，測試者在取得授權後模擬攻擊者行為，目標是在上線前找出弱點並通知開發團隊修補，而非刻意破壞應用程式。
重點整理
重點- 1
滲透測試的目的是找漏洞、給修補，而非破壞系統。 真實場景中，測試者在取得授權後模擬攻擊者行為，目標是在上線前找出弱點並通知開發團隊修補，而非刻意破壞應用程式。
- 2
測試前必須徹底理解應用程式業務邏輯與角色權限。 講師強調在動手測試前，要與開發團隊開會，釐清使用者角色（Customer、Support、Admin）、敏感資料範圍、關鍵工作流程及測試範圍（Scope），再製作角色矩陣（Role Matrix）才能有系統地執行授權測試。
- 3
Burp Suite 作為代理（Proxy）可完整攔截與重放 HTTP 流量。 透過 HTTP History 掌握所有請求、使用 Repeater 手動重放與修改參數、再以 Intruder 批次自動化枚舉，是發現 IDOR 等存取控制漏洞的標準操作流程。
- 4
IDOR 漏洞核心在於伺服器端缺少授權驗證。 應用程式直接將內部物件識別碼（Basket ID）暴露於 API 路徑，且未在伺服器端確認請求者是否有權存取該資源，導致攻擊者只需修改 ID 數字即可橫向存取其他用戶資料。
- 5
--
實用技巧與重點
乾貨- 工具與環境
- Burp Suite Community Edition（可從 portswigger.net 下載）
- OWASP Juice Shop（靶機，部署於 AWS EC2，使用 Docker Image）
- Burp Suite 內建 Chromium Browser（已整合 Proxy）
- Mobile Xterm（SSH 連線至 AWS EC2 伺服器）
- HTTP 方法
- GET：讀取資料
- POST：建立新資料（如註冊、新增購物項目）
- PUT：完整更新資料
- PATCH：部分更新資料
- DELETE：刪除資料
- HTTP 狀態碼
- 200 OK：請求成功
- 201 Created：資源成功建立
- 304 Not Modified：快取未變更
- 401 Unauthorized：未通過認證
- 403 Forbidden：已認證但無授權
- 404 Not Found：資源不存在
- 500 Internal Server Error：伺服器端錯誤
- 發現的漏洞（實際示範）
- 匿名用戶可提交任意評分（超過上限 5 分，輸入 50 仍被接受）→ Business Logic Vulnerability
- Repeater 可重放相同回饋請求，無限次建立重複評論 → Replay Attack
- 修改 POST 請求中的 `author` 欄位可冒充其他用戶 → Impersonation（嚴重度：High）
- IDOR：GET `/rest/basket/{id}` 端點僅驗證 JWT Token 存在，未驗證 Token 是否對應該 Basket ID → 以同一 Token 存取 Basket 1–10 全部回傳 200 OK
- IDOR 實際操作步驟
- 登入後加入商品至購物籃，攔截 GET `/rest/basket/7` 請求
- 送至 Repeater，確認回傳自己帳號（User ID: 25）的購物籃資料
- 將路徑中的 `7` 改為 `2`，送出後得到 User ID: 2 的購物籃資料（Raspberry Juice）
- 送至 Intruder，設定 Sniper Attack，Payload 為數字 1–10，Step 1
- 啟動攻擊，Basket ID 1–10 全部回傳 200 OK，成功列舉所有用戶購物籃
- 滲透測試報告必要欄位
- Title（漏洞名稱）
- Severity（嚴重度，此案例為 High）
- Technical Description（技術說明）
- Impact（影響）
- Proof of Concept（截圖 + 重現步驟）
- Recommendation（修補建議：實作伺服器端每次物件存取的授權驗證）
- 修補建議
- 伺服器端針對每個物件存取請求實作授權驗證（Server-side Authorization Validation）
- 滲透測試前置步驟
- 與應用程式團隊開會，理解業務邏輯與使用者角色
- 定義測試範圍（In-scope URL、API；Out-of-scope：生產資料庫、第三方頁面）
- 取得各角色測試帳號
- 建立角色矩陣（Role Matrix）：列出每個角色對每個功能的存取權限
- --
結論
結論“IDOR 漏洞的根本原因是伺服器端缺乏逐次授權驗證，只要能修改 URL 中的物件 ID 就能橫向存取他人資料，而 Burp Suite 的 Repeater 與 Intruder 是快速發現並批量驗證此類漏洞的最直接手段。”
完整解析
詳細Web 應用程式滲透測試（Pentesting）的目標是在應用程式正式上線前，模擬真實攻擊者的行為，找出安全弱點並提交修補建議，而非破壞系統。講師以客戶服務模型（Client-Server Model）作為基礎概念切入：瀏覽器（Chrome）是客戶端，部署在 AWS EC2 上的 OWASP Juice Shop 是伺服器端，所有互動都透過 HTTP 請求與回應完成。Burp Suite 作為中間人代理（Proxy），能完整攔截並記錄這些流量，是 Web 滲透測試的核心工具。
在正式測試前，講師強調「了解應用程式」是不可省略的前置作業。測試者需要與開發團隊開會，確認應用程式的業務邏輯、使用者角色（Customer、Support、Admin）、敏感資料的所在、測試環境範圍（UAT 而非生產環境）。接著建立角色矩陣，逐功能標注各角色是否有權存取，例如 Admin 可刪除訂單，而 Customer 和 Support 不行。這個矩陣直接成為後續授權測試的測試案例清單，大幅提高測試效率與覆蓋率。
實際操作部分，講師以 OWASP Juice Shop 示範了數個漏洞。首先在匿名狀態下提交評論，透過 Burp Suite Repeater 發現可無限重放請求（Replay Attack），並可修改請求中的 `author` 欄位冒充他人（Impersonation）；評分欄位接受超出正常範圍的數值（輸入 50 依然被接受），屬於 Business Logic Vulnerability。接著進入本次課程的主軸——IDOR（Insecure Direct Object Reference，不安全的直接物件參考）。講師登入後將商品加入購物籃，攔截到 `GET /rest/basket/7` 的請求，這個 `7` 就是直接暴露的內部物件識別碼（Basket ID）。在 Repeater 中將 `7` 改為 `2`，伺服器回傳 200 OK 並吐出其他用戶的購物籃內容，確認漏洞存在。最後利用 Intruder 的 Sniper Attack 模式，以數字 1–10 批次枚舉，所有 Basket ID 均回傳 200 OK，代表任意登入用戶都能用單一 JWT Token 橫向存取所有人的購物資料。
課程最後講師展示了滲透測試報告的格式：標題、嚴重度（High）、技術說明、影響範圍、截圖與重現步驟，以及修補建議——伺服器端應在每次物件存取時驗證請求者的 Token 是否對應該資源的擁有者。他並總結幾條實務原則：測試前必須先理解應用程式、製作角色矩陣、理解 API 架構、工具是輔助而非替代思考，以及所有發現都必須驗證後再提報，避免誤報浪費開發團隊的時間。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
