讀 CAPEC 時，如果看完標題和編號就關掉，很容易把它誤認成另一份漏洞類型清單。真正有意思的其實藏在 execution flow：它會試著還原攻擊者從找入口、測試邊界，到最後完成利用的過程。

以 Relative Path Traversal（CAPEC-139）為例，攻擊者通常不是一開始就知道伺服器的完整目錄結構。他可能先找出帶有檔名、路徑或下載參數的功能，再用不存在的檔案、不同層數的 ../、編碼字元或平台分隔符號觀察回應。

單看每一個動作可能都沒什麼，串起來之後，才會變成一個完整的攻擊模式。

Explore：先找得到入口

第一階段常是盤點可控制的位置。例如下載功能中的 file、語系切換中的 template，或圖片預覽 API 的 path。錯誤訊息、回應時間與 HTTP 狀態碼，都可能透露後端是否真的碰了檔案系統。

這裡還沒有證明漏洞。允許使用者提供檔名本身很正常，關鍵在於後端如何解析、正規化並限制最後的路徑。

Experiment：測試邊界在哪裡

接著是試探。單純的 ../ 可能被擋，但 URL encoding、重複編碼、Windows 與 Unix 分隔符號，或應用程式與反向代理的解碼順序，都可能造成不同結果。

測試的目的不是無止境變換 payload，而是回答幾個問題：輸入在哪一層被解碼？應用程式有沒有 canonicalize？檢查發生在解析之前還是之後？錯誤回應是否能區分「檔案不存在」和「路徑不允許」？

Exploit：取得原本不該取得的資源

確認能越過目錄邊界後，攻擊者才會嘗試讀取設定檔、憑證、原始碼或其他敏感資源。能讀到什麼，仍受執行帳號權限、容器掛載與作業系統存取控制限制。

因此，Path Traversal 不應自動被描述成「可讀取主機所有檔案」。比較準確的說法是：攻擊者可讓應用程式存取允許目錄之外、且該程序本身有權讀取的檔案。

Execution flow 不是固定劇本

CAPEC 提供的是可重用的模式，不是每個案例都必須逐步照演。白箱測試可能直接從程式碼看到失效點，不需要探索；某些 API 也可能因錯誤訊息太少，無法用回應推測目錄結構。

使用 CAPEC 的價值，是檢查一份報告有沒有漏掉重要條件。例如只附上一個 payload，卻沒說入口在哪、需要登入嗎、回應如何證明越界、程序權限又限制了哪些結果。沿著攻擊階段追問，通常比單純要求「再給一個 PoC」更有效。

從攻擊模式回頭看防禦

每個階段都可能有不同防禦點：減少詳細錯誤可降低探索資訊；統一解碼與 canonicalization 可避免檢查落差；以 allowlist 對應伺服器端資源，可以避免直接接受路徑；最小權限則限制成功利用後的影響。

所以防禦不是看到 ../ 就全部擋掉，而是想辦法打斷整條利用路徑。這也是 CAPEC 比單看一條 payload 更值得讀的地方。