這是一個非常經典的安全性漏洞案例，涉及到了 Web 開發中經常被忽視的 Path Normalization（路徑正規化）問題。簡單來說，當系統中兩個不同的組件對同一個 URL 路徑的理解不一致時，就可能產生安全漏洞。
這次的問題發生在 AWS API Gateway 的 HTTP API 版本（這是比 REST API 更輕量且便宜的選擇）。研究人員發現，只要在 API 路徑末尾加上一個反斜線（Trailing Slash），就可以完全繞過 Lambda Authorizer 的身份驗證。
讓我們以一個實際例子來理解：當請求路徑是 /v1/accounts 時，系統會正確返回 401 Unauthorized（未經授權）；但如果請求路徑改為 /v1/accounts/，系統竟然會返回 200 OK 並洩漏所有帳戶數據。
為什麼會發生這種情況？這涉及到 HTTP API 內部的兩個層級：路徑匹配層（Route Matching Layer）與授權層（Authorizer Layer）。
路徑匹配層負責決定這個請求應該發送到哪個後端。由於 HTTP API 預設使用 Greedy Path Matching（貪婪路徑匹配），它認為 /v1/accounts/ 是以 /v1/accounts 為前綴的合法路徑，因此允許請求通過。
然而，問題出在授權層。當請求進入授權流程時，授權層與路徑匹配層對路徑的判定產生了分歧。在某些情況下，這種不一致導致授權上下文（Authorization Context）在傳遞到後端 Lambda 函數之前被丟棄或失效。
對初級工程師來說，最關鍵的風險在於後端 Lambda 函數的信任機制。通常，Lambda Authorizer 會在驗證成功後，將 userId 等資訊放入 context.authorizer 中傳給後端。如果後端 Lambda 盲目信任這個欄位，而沒有檢查它是否為空，就會產生災難。
在本案例中，當加上反斜線導致授權上下文遺失時，userId 變成了 undefined。而後端 Lambda 因為沒有對 undefined 進行驗證，反而將其視為系統管理員權限，導致攻擊者能獲取所有數據甚至執行轉帳操作。
這種漏洞的核心在於缺乏 Canonical Path（標準路徑）的統一處理。所謂標準路徑，是指將所有變體（例如多餘的反斜線、點號等）統一轉換為一種唯一格式後再進行權限檢查。如果系統在進入授權層之前就拒絕所有非標準路徑，這個漏洞就不會存在。
針對使用 AWS HTTP API 的團隊，有幾個實務上的建議可以防止類似問題。
首先，不要將授權層視為唯一的防線。後端 Lambda 函數必須實作防禦性編程，獨立驗證授權上下文中的欄位，絕對不能假設只要請求到達後端就一定是經過驗證的。
其次，應審核 API 的路徑行為。測試時應刻意嘗試在路徑末尾添加反斜線，觀察返回結果是否與正常路徑一致。
最後，在選擇工具時要權衡成本與安全性。AWS 的 REST API 雖然價格較高，但其路徑匹配機制比 HTTP API 嚴格許多。對於涉及金融或敏感數據的端點，使用更嚴謹的 REST API 或在前端閘道器強制執行路徑正規化是更安全的做法。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。