API 突增的攻擊面成長
API 的快速成長已帶來安全風險
應用程式開發介面 (API) 是一種運算介面，用於定義並實現不同軟體之間的互動。許多日常工作都要歸功於 API，包括在社交平台上分享媒體、處理線上支付以及彙總網站分析資料。透過雲端運算，企業可以藉助 API，更輕鬆地部署全球基礎結構。
如今，大多數軟體使用或本身就是 API，而在過去的 4-5 年中，API 呈指數級增長。例如，API 開發協作平台 Postman 的 API 資料夾數量從 2016 年的不到 50 萬，在 2021 年劇增 到近 3500 萬。
儘管 API 受歡迎程度急劇上升，但相關的安全措施仍然落後。現在，隨著閘門越開越大，各種重大漏洞已經浮出水面。根據 Gartner 的預測，由於爆炸式增長和開發不足的安全性相結合，API 預計將成為有史以來最大的安全漏洞。
API 優先開發的迅速增長
API 增長的主要驅動因素之一是微服務的激增，微服務在 2013 年開始流行起來。微服務架構樣式開發使用 API 相互通訊的小型獨立應用程式。這樣，複雜的任務可以分解為更小的部分，並且每個部分都獨立開發和維護。
2018 年全球微服務架構市場價值為 20.7 億美元，預計到 2026 年將達到 80.7 億美元（2019-2026 年年均復合增長率為 18.6%）。由於具有靈活性、更快的開發週期和卓越的可擴展性，微服務已被廣泛採用。
例如，為跟上需求，Netflix 從集中的整合型資料中心轉為基於雲端的微服務架構。結果為開發人員帶來了巨大的自由度，可以不斷改善客戶體驗，例如根據特定地理區域定制內容的能力。
使我們生活在 API 優先世界的趨勢也給了我們發現漏洞的線索。API 無處不在，並持續成長。因此，風險也是如此。
API——新的巨大安全漏洞
廣泛的 API 相關開發和活動不會轉化為安全的應用程式。據 Gartner 所說，相比使用者介面 (UI)，90％ 啟用 Web 的應用程式在暴露的 API 中具有更大的攻擊面區域。Gartner 還預測，2022 年，API 濫用行為將從不常見的攻擊媒介轉變為最常見的攻擊媒介。
API 漏洞存在於廣泛的領域，例如端點（裝置、伺服器、虛擬環境等）、資料暴露、阻斷服務 (DoS)、授權缺陷、安全系統設定錯誤等。考慮到任何組織中與數千個 API 支援的資產相關的巨大攻擊面，API 漏洞對企業可能產生極其廣泛的影響。
範例包括資料損毀、資金遭竊、生產力損失、智慧財產權竊取、個人和財務資料遭竊、詐騙、業務營運中斷，以及還原和/或刪除受損資料和系統的成本。與 API 洩露相關的聲譽損害也可能導致信任降低，這在任何嚴重的安全事件中都很常見。
儘管公司採取了強有力的安全措施，但仍遭受 API 攻擊的知名案例已經成為頭條新聞。看看 Facebook 的範例，透過攻擊該網站的「檢視方式」功能中的弱點，導 致 5000 萬個帳戶暴露。這讓駭客得以在 Facebook 建立 API 支援的影片上傳功能後竊取帳戶存取權杖。
Uber 也遭遇了一次暴露事件，其使用者在 API 要求中的通用唯一識別碼 (UUID) 導致 API 回應中的權杖洩露，可用於劫持帳戶。然後，攻擊者能夠追蹤受害者的位置，甚至竊取乘車機會。
Facebook 和 Uber 案例展示了所謂的「使用者驗證受損」API 攻擊。當驗證未正確實作時，可能導致驗證權杖洩露和其他導致使用者身分盜竊的缺陷。
由於與 Covid-19 相關的家庭辦公工作增加，住宅 IP 位址的大量使用使得將惡意 API 呼叫與合法 API 呼叫分離開來變得更加重要。認證填充或垃圾訊息殭屍網路攻擊可能使用多達 10,000 個不同的 IP，其中包括被駭客入侵的伺服器、工作站甚至 IoT 裝置。
阻止 API 攻擊需要正確的策略 + 正確的網路
由於 API 會暴露應用程式邏輯和敏感性資料（例如個人識別資訊 (PII)），因此它們對組織的基礎結構和安全性策略至關重要。但是傳統的 Web 應用程式安全策略（其中許多依賴「被動安全性」模型）可能無法阻止大多數 API 威脅。
透過主動安全性實現 API 防禦
在「被動安全性」模型中，除了位於已知或可疑威脅的封鎖清單中的要求，其他要求都能通過 Web 應用程式防火牆 (WAF)。這個模型可能會造成誤判（封鎖合法 API 呼叫的情況），也可能無法捕捉到一些更具針對性的攻擊。但是，WAF 在 API 安全性方面確實具有至關重要的作用。例如，通過結構描述驗證的幾個階段（如端點、方法和參數）的經驗證流量可能仍然攜帶 SQL 攻擊，而 WAF 可以捕捉到這種攻擊。此外，某些 API 不適用於 TLS 或提出結構描述驗證挑戰。如果結構描述不是最新，或者 API 分散且難以合併到單一結構描述中，WAF 將有助於填補缺口。
也就是說，僅依賴以封鎖清單為中心的 WAF 來實現 API 安全性會導致組織容易受到攻擊。API 威脅緩解可藉助 API Shield 之類的「主動安全性」模型來避免這些風險，該模型僅允許已知行為，而會識別和拒絕其他所有內容。
邁向主動模式的一個關鍵步驟是部署不易受到密碼重用或分享密碼影響的強驗證和授權，例如 TLS 或 OAuth。管理權限和憑證共用可能非常耗時，因此開發人員應該優先考慮盡可能簡化允許清單程序的工具。
當然，從裝置中擷取憑證並在其他地方重複使用的情況並非不可能。開發人員還需要一種方法來驗證 API 呼叫本身。結構描述驗證可以透過將 API 要求的內容（位於 POST 內文的 URL 和內容之後的查詢參數）與包含預期內容之規則的合約或 「結構描述」進行比對，以達到此目的。如果驗證失敗，則會封鎖 API 呼叫，以防止原始伺服器受到無效要求或惡意負載的影響。
阻止 API 攻擊——網路強化個人工具
雖然透過驗證/授權和 API 呼叫驗證實現主動安全性很重要，但還需要額外的安全措施。例如，API 仍然容易遭受巨流量攻擊、暴力密碼破解嘗試和憑證填充等攻擊。因此，DDoS 緩解和限速仍然是企業整體安全狀態中的必要工具。
在 DDoS 緩解和限速等現有工具中新增新的安全工具可能會帶來挑戰。當 API 呼叫通過許多不同的工具時，監控和記錄會變得更加繁瑣。此外，透過分散各地的資料中心中的不同工具輸入流量，可能會增加延遲並降低應用程式效能。
出於這些原因，最好是使用整合到更大邊緣網路中的多種安全功能來提供 API 安全性，這能夠提供以下優勢：
復原能力：如果多個邊緣網路位置可以託管 API 安全工具，單獨的中斷帶來的風險會更小。
降低延遲：如果多個 API 安全工具在同一個邊緣網路位置中運作， 則流量不必在不同位置之間往返。
威脅情報：如果邊緣網路有足夠的覆蓋範圍，它可以分析大量 API 所遭受的攻擊，並使用此情報來更好地保護其他 API。
更容易記錄：使用單一網路（透過單一管理平台操作）可為開發人員提供單一事實來源。
Cloudflare 專為現代企業架構打造，透過使用強大的用戶端憑證型身分識別和嚴格的結構描述驗證，讓您輕鬆保護 API 的安全。這是一種智慧型且可擴充的解決方案，可保護您的業務關鍵型 Web 應用程式免受惡意攻擊，且無需變更現有基礎結構。
Cloudflare 就影響當今技術決策者的最新趨勢和主題發表了一系列文章，本文為其一。
重點
閱讀本文後，您將能夠瞭解：
API 使用的增長速度
攻擊面區域如何隨著 API 擴展
阻止這種風險的策略
整合式平台的優勢