幽靈 API 是已棄用但仍處於活動狀態的端點，這會使系統面臨攻擊風險。了解它們與影子 API 的區別，以及為何它們會造成隱藏的安全風險。
想像一下，一家銀行三年前升級了其行動應用程式。舊的 v1/transfer 介面已被棄用並從文件中移除，但伺服器從未停用。如今，攻擊者利用快取的舊版應用程式繞過了現代多因素身份驗證 (MFA)，因為 Ghost API 仍然遵循舊的安全協定。系統不會發出任何警報，也不會標記任何異常。該接口本應已失效，但它卻依然存在。這並非假設的極端案例，而是正在大規模雲端基礎設施中上演的一種普遍模式，而業界對此尚無可靠的解決方案。
以2022 年 Optus 資料外洩事件為例：一個最初建構用於透過子網域提供客戶資料的 API 端點，由於 2018 年引入的編碼錯誤而實際上未經過身份驗證。該端點從未被棄用、從未被移除、也從未被監控。
四年後，一名攻擊者發現了這個漏洞，無需憑證，僅憑反覆嘗試就成功查詢了系統，竊取了950萬澳大利亞人的個人記錄。澳洲通訊與媒體管理局後來指出，在漏洞被利用之前，Optus至少有三次機會發現並修復漏洞，但他們一次也沒有把握。
即使 API 已被正式棄用，那些仍可存取的遺留端點仍然代表著日益增長且尚未有效解決的安全隱患。這並非個別問題，而是雲端規模系統在管理自身生命週期時所存在的結構性缺陷。
幽靈 API 與影子 API：非同一問題
這兩個術語經常被混淆。區分它們很重要。
影子 API 是發現問題，幽靈 API 是執行問題。你無法透過改進 API 目錄來修復幽靈 API；它已經在目錄中，並被標記為已棄用。問題在於，將其標記為已棄用並沒有使其無法存取。
「貶低」的假安全感
每個 API 都有一個開始，但很少有 API 能有一個清晰的結束。隨著企業採用微服務架構並加快發布週期，API介面迅速擴展。每個新服務版本都會引進新的端點，而舊版本則長期存在。團隊會遷移到新版本，文件也會更新，但這些端點本身通常仍然可存取，默默地回應無人監控的請求。
在雲端規模下刪除已棄用的 API 需要回答一個出乎意料地難以確定答案的問題：是否還有人使用它？在大型分散式系統中，答案往往並不顯而易見。使用者分散在各個團隊、組織，有時甚至涉及第三方整合。依賴項的文檔充其量也只是部分記錄。來自舊工作流程的低頻呼叫可能會在官方棄用期限過後持續使用數年。
這會產生一種理性但危險的激勵機制：為了避免破壞未知功能，寧願保持 API 的正常運作。規模化之後，生命週期管理會變成一個協調難題，任何單一團隊都無法手動解決。最終導致架構的預期形態與實際生產環境運作的狀況之間差距越來越大。
2023 年T -Mobile API 資料外洩事件中，攻擊者透過管理不善的 API 在 40 天內悄無聲息地從 3700 萬個帳戶中竊取了資料。這表明，即使是擁有專門安全團隊的組織，這些漏洞也可能長時間不被發現。
多種因素加劇了這種失敗：
✔ 長尾消費者在遠超既定時間表後仍繼續使用已棄用的介面。
✔ 即使在文件管理規範完善的組織中，依賴關係圖也往往不完整。
✔ 移除終端會帶來不對稱風險：破壞消費者的成本是立竿見影且顯而易見的，而保留終端的成本則是分散且落後的。
✔ AI輔助開發工具的程式碼補全功能，以及基於LLM的輔助程序，可以透過利用棄用之前的訓練數據，悄無聲息地恢復已棄用的API調用，生成引用開發者從未了解過的端點的代碼。
API治理架構主要著重於命名、版本控制和生命週期策略，並不會強制執行執行階段行為。例如，即使策略聲明“此API已棄用”，也不會導致API無法存取。
攻擊者如何找到幽靈API
讀者通常會認為文件頁面被移除就意味著介面也被移除。但攻擊者心知肚明。以下是一些常用的暴露 Ghost API 的技術：
✔ 目錄暴力破解。自動化工具會偵測/v1/, /v2/, /beta/, /legacy/, /test/運作中的主機上是否存在可預測的版本控制模式。如果伺服器回應，則無論文件如何描述，該端點都處於運作狀態。
✔ 網路檔案館（Wayback Machine）、 Archive.org 和類似服務會快取舊的 API 文件、SDK 變更日誌和開發者入口網站的快照。攻擊者可以取得兩三個版本前 API 的完整端點結構，然後偵測運作中的系統，查看哪些功能仍然有效。
✔ 硬編碼且安全性較弱的憑證。舊版介面通常依賴靜態 API 金鑰、基本驗證或安全性較弱的令牌方案，這些方案早於現代憑證管理實務。這些憑證更容易從舊客戶端二進位檔案、行動應用程式或公共程式碼庫中提取，而 Ghost API 通常仍然會接受它們。
✔ GenAI輔助偵察。威脅面已在此發生顯著變化。基於GitHub程式碼庫、Stack Overflow討論串、開發者部落格和存檔變更日誌等公開資料訓練的大型語言模型，已經吸收了企業以為早已消失的多年API文件。
攻擊者只需知道服務名稱和大致使用年代，就能藉助 LLM 工具重建已棄用 API 的可能端點結構、參數名稱和驗證模式。以前需要花費數小時在存檔資源中進行手動研究才能完成的工作，現在只需幾分鐘即可完成。 LLM 工具還能加速產生針對特定公司命名規範而非通用模式的定向暴力破解字典。
這種組合非常強大：透過存檔文件或 LLM 輔助重建找到舊端點，使用從舊應用程式中提取的憑證進行身份驗證，並繞過添加到當前 API 版本中的所有安全控制。
為什麼幽靈 API 會破壞零信任？
遺留API不僅是技術債務，它們也是實實在在的安全隱患。多年前建立的 API 早於現代安全控制措施。身份驗證機制不斷發展，多因素身份驗證 (MFA) 的要求也日益嚴格，零信任架構取代了隱式信任模型。然而，五年前或十年前的「幽靈 API」卻不具備這些改進。它仍然沿用建構時的時代安全假設。
這會造成結構性錯位。 API安全風險經常透過過時的介面顯現出來，正是因為這些介面繞過了應用於當前端點的控制措施。它們更難監控、更難審計，在某些情況下甚至更難發現，尤其是在公共文件被移除但端點本身仍在線的情況下。
隨著企業將生命週期管理 (LLM) 整合到自身產品中，問題日益嚴重。能夠自主調用 API、檢索資料、觸發工作流程並與後端服務互動的 AI 代理和輔助程式引入了一種新型的消費者，這種消費者難以審計，並且可能完全無視棄用訊號。一個基於舊版內部文件訓練或微調的 LLM 驅動的代理，無需任何人工編寫，即可開始呼叫 Ghost API。消費者是真實的，流量也是真實的，但對於負責生命週期管理的團隊而言，這種依賴關係卻是看不見的。
零信任模型明確規定：不存在隱性信任，持續驗證，並在每次互動中遵循最小權限原則。幽靈 API 違反了所有這些原則。它們之所以能夠持續存在，並非因為有人授予了它們持續的信任，而是因為沒有人主動撤銷這種信任。在零信任架構中，這種差異至關重要。已棄用的 API 是一種策略狀態，而無法存取的 API 則是一種安全狀態。這兩種狀態之間的空白區域正是幽靈 API 的藏身之處，也是攻擊者活動的區域。
補救措施的三個關鍵步驟
前進的道路並不需要對平台進行徹底改造，而是需要按部就班地貫徹執行操作規範。
- 第一步：流量分析。部署服務網格工具（Istio、Linkerd 或同類工具）來擷取存取那些沒有有效文件或所有權的端點的流量。任何接收無法歸因於已知目前使用者的請求的端點都應進行調查。這可以發現團隊之前不知道仍在使用的“幽靈 API”，並將真正的長尾用戶與自動化掃描器區分開來。
- 步驟二：強制測試。在刪除已棄用的端點之前，先將其停用 24 至 48 小時，並監控是否有使用者提出實際問題。如果沒有使用者提出任何問題，則可以安全地移除該端點。這種方法將「萬一有人正在使用它怎麼辦」的擔憂從阻礙因素轉化為可測試的假設。它還創建了審計追蹤：刪除決策是在受控測試的基礎上做出的，而不是憑猜測。
- 步驟三：基於身分的強制執行。將所有活躍端點的廣泛、長期有效的 API 金鑰過渡到短期、身份範圍限定的令牌。顧名思義，被忽視的“幽靈 API”不太可能更新以支援現代令牌方案。這自然地劃分了強制執行邊界：當前端點使用當前憑證；無法更新以支援這些憑證的舊端點將被停用。此外，這也消除了硬編碼金鑰攻擊的途徑，而這正是「幽靈 API」最初成為攻擊目標的原因。
這些步驟並非完美的解決方案，但它們切實可行，能夠產生證據，並能促使組織從被動累積轉向積極的生命週期管理。
產業需要建構什麼
以上三步驟是戰術性的，而結構性的修復則是架構性的。產業需要轉變觀念，不再僅僅將棄用視為一種溝通手段，而是將其視為一種強制性的狀態變更。這意味著要將 API 生命週期管理視為一項持續的運維工作，建立能夠從實際流量而非用戶自述的依賴關係圖中識別活躍用戶的系統，隨著用戶遷移逐步限制存取權限，並將刪除操作變成一個可驗證、可審計的事件，而不是一項盡力而為的手動操作。
這一切都不需要發明新的安全機制。使用情況遙測、存取控制和生命週期狀態管理的基本要素存在於每個成熟的雲端平台中。所缺乏的是將這些要素整合到一個自動化治理循環中的運維規範，從而以與創建端點相同的嚴格標準來對待端點移除。
當未受管理的端點無限期地保持可存取狀態時，分散式系統安全挑戰會進一步加劇。攻擊面不僅會擴大，而且會以難以清點的方式擴大，僅靠邊界控制幾乎無法防禦。彌合這一差距的組織不僅會縮小攻擊面，還會建立現代合規框架日益要求的、可驗證、可審計的 API 安全機制，而這正是注重安全性的客戶開始提出的要求。
最危險的API是那些無人監管的API
安全產業針對主動威脅擁有一套完善的術語體系。但對於被動風險，並非來自攻擊者的行為，而是來自組織未能有效清理的風險，其術語體系則相對薄弱。
幽靈 API 是大規模被動曝光的一個典型案例。它們不會主動發出警報，也不會觸發安全警報。它們只是默默存在，沿用著舊時代的安全假設，任何知道或能夠找到它們的人都可以存取。
減少雲端安全債務意味著要像重視威脅偵測一樣重視生命週期管理。系統中風險最大的 API 通常並非正在遭受攻擊的 API，而是那些已被遺忘、策略中已棄用，但仍可存取、仍受信任且仍在等待的 API。
資料來源：https://hackread.com/deprecated-endpoints-attacker-best-friend-ghost-apis/