BadHost 漏洞解析：當基礎框架的微小缺陷演變成 AI 系統的重大危機
近期在 Python 社群中廣泛使用的 Web 框架 Starlette 中發現了一個高風險的認證繞過漏洞，被命名為 BadHost。由於 Starlette 是許多知名框架（如 FastAPI）的底層基礎，且每週下載量高達 3.25 億次，這次漏洞的影響範圍極其廣泛，特別是對於部署在內部網路中的 AI Agent、LLM 評估系統以及 LLM 閘道器（LLM Gateway）構建者而言，這是一個必須正視的安全威脅。
理解漏洞的核心：Host 標頭的解析陷阱
要理解這個漏洞，我們得先從 HTTP 請求的構造說起。當客戶端發送請求時，會攜帶一個 Host 標頭（Host Header），告訴伺服器目標主機是誰。
在 Starlette 的處理邏輯中，它會將這個 Host 標頭與請求路徑（Request Path）拼接在一起，重新解析成一個完整的 URL 物件，供後續的程式碼使用。然而，Starlette 在拼接前並沒有根據標準規範（RFC 9112 / RFC 3986）對 Host 標頭進行嚴格的驗證。
攻擊者可以利用這一點，在 Host 標頭中惡意加入特殊字元，例如斜線（/）、問號（?）或井字號（#）。這會導致 Starlette 在重新解析 URL 時，將路徑、查詢參數（Query）或片段（Fragment）的邊界產生偏移。
簡單來說，ASGI 伺服器（一種 Python 的非同步伺服器介面）接收到的實際請求路徑可能是 /admin，但經過 Starlette 錯誤的重新解析後，程式碼讀取到的 request.url.path 可能會變成其他值。如果開發者在中間件（Middleware）中使用 request.url.path 來判斷使用者是否有權限訪問 /admin，攻擊者就能透過操縱 Host 標頭，讓認證檢查被跳過，從而非法進入管理後台。
為什麼 AI 基礎設施更容易受害
雖然這個漏洞在通用 Web 應用中已經很嚴重，但對於 AI 系統來說，風險被進一步放大，原因有三。
首先是部署環境的差異。許多 AI 服務、LLM 研究環境或實驗室子網，為了方便開發，往往直接將 Starlette 或 FastAPI 暴露在網路中，而沒有配置反向代理（Reverse Proxy）或 API 閘道器。在標準的生產環境中，像 Nginx 或 CDN 這樣的前端設備通常會過濾掉不合法的 Host 標頭，但 AI 內部環境缺乏這層防護，使得 BadHost 漏洞可以直接被觸發。
其次是 AI 生態的新標準。研究人員指出，MCP（Model Context Protocol，模型上下文協定）伺服器面臨極高風險。因為 MCP 規範要求提供無需認證的 OAuth 探索端點，這為攻擊者提供了一個可靠的進入點，可以用來測試並利用此漏洞。
最後是漏洞的連鎖反應。這不是單一檔案的 Bug，而是三個層級的信任崩潰：ASGI 伺服器原封不動地傳遞 Host 標頭，Starlette 信任該標頭來構建 URL，而中間件開發者則假設 request.url.path 是安全且可信的。這種信任鏈的斷裂，使得單純的認證繞過能迅速演變成伺服器端請求偽造（SSRF）甚至遠端程式碼執行（RCE）。
工程實務上的建議與對策
對於開發者與維運工程師，建議採取以下行動。
第一，立即更新。Starlette 已在 1.0.1 版本中修復此問題。請檢查所有依賴 FastAPI 或 Starlette 的專案並更新至最新版本。
第二，強化邊界防禦。不要將 Python Web 框架直接暴露在公網。部署反向代理（如 Nginx, Traefik）或使用雲端 API Gateway，這些工具能有效攔截不符合 RFC 規範的 HTTP 請求。
第三，重新審視認證邏輯。在撰寫安全相關的中間件時，應意識到從框架獲取的 URL 屬性可能被操縱。盡量使用經過驗證的請求路徑，而非完全依賴框架自動構建的 URL 物件。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。