API十大安全威脅解析及API網關的安全防護。

譯自Mitigate OWASP Security Top Threats with an API Gateway，作者 David Sudia 是 Ambassador Labs 的高級開發(fā)者倡導者，該公司是 Emissary-Ingress 和 Telepresence 的創(chuàng)建者。他之前是 DevOps/平臺工程師和 CNCF 最終用戶。Dave 熱衷于通過確保開發(fā)者做出最好的工作來支持其他開發(fā)者......

OWASP 每四年會發(fā)布一次OWASP Top 10，其中描述了最關鍵的安全風險。這個列表是組織了解和緩解常見 Web 漏洞的起點。

自 2019 年以來，該組織還制定了一個針對 API 安全威脅的前 10 名，以提高人們對 API 安全的認識，并提供解決最緊迫威脅的指導。這些映射了一般安全威脅到 API 面臨的具體問題。

隨著越來越多的應用程序和平臺提供 API 以方便集成、開發(fā)和自動化，與這些 API 關聯(lián)的安全問題也在相應地上升。API 常常扮演應用程序數(shù)據(jù)、業(yè)務邏輯和敏感功能的網關，這使得它們成為攻擊者的誘人目標。如果未得到適當安全保護，它們可能被利用來泄露敏感信息、繞過安全控制或者甚至操縱基礎系統(tǒng)。

OWASP API 安全項目在 7 月發(fā)布了新的前10 大 API 安全威脅。讓我們回顧這個列表的要點，以及 API 網關工具如何幫助減少這些漏洞。

最大的安全威脅：授權

損壞的授權已經成為應用程序正在承受的最大 API 安全威脅。2023 年名單中前 10 大 API 安全威脅中有 3 個與授權相關:

• 損壞的對象級授權：對象級授權確保用戶只訪問被允許的對象。接收對象 ID 的 API 必須驗證用戶對這些對象的操作權限。不足的檢查可能導致未經授權的數(shù)據(jù)更改。
• 損壞的對象屬性級授權：API 常常暴露所有對象屬性，特別是 REST API。檢查 API 響應可以揭示敏感信息，而模糊測試可以檢測隱藏屬性。未經授權的屬性訪問可能導致數(shù)據(jù)泄露或賬戶被接管。
• 損壞的函數(shù)級授權：攻擊者通過匿名或普通用戶身份訪問不應訪問的 API 端點來利用損壞的函數(shù)級授權。復雜的角色和用戶層次結構使適當?shù)氖跈鄼z查變得艱巨。然而，API 的結構化特性使缺陷更容易被發(fā)現(xiàn)。這些漏洞允許未經授權的函數(shù)訪問，冒著數(shù)據(jù)泄露或服務中斷的風險。

永恒的安全威脅：認證

盡管隨著服務提供商的認證服務向開發(fā)者開放，損壞的認證仍然是 API 安全威脅名單上的第 2 名。認證是驗證試圖訪問您的 API 的用戶或系統(tǒng)的身份。由于這些是您服務的“前門”，它們是攻擊者的首要目標。

錯誤發(fā)生在開發(fā)人員嘗試構建自己的認證系統(tǒng)時。對認證限制及其復雜實現(xiàn)的誤解使漏洞很常見。攻擊者可以劫持用戶賬戶、訪問個人數(shù)據(jù)并在真實用戶無法區(qū)分的情況下執(zhí)行敏感操作。

為了解決這個威脅，您會想要通過 API 網關為應用程序提供可靠的認證。使用使用 JSON Web 令牌(JWT)、OAuth 和其他基于令牌的認證系統(tǒng)等認證機制的網關，以確保安全的用戶體驗。這些基于令牌的方法提供了一種可擴展和安全的方法來確認用戶身份，而不需要不斷交換敏感憑據(jù)。

無論您選擇哪個 API 網關，請確保它可以根據(jù)經過身份驗證的用戶執(zhí)行速率限制。這是一個關鍵功能，因為它可以通過限制用戶可以提出的請求的頻率來防止?jié)撛诘臑E用。例如，通過將速率限制與特定的經過身份驗證的配置文件相關聯(lián)，Edge Stack 等選項可以確保系統(tǒng)資源不會過載，并抑制惡意嘗試淹沒系統(tǒng)的行為。這種特定于用戶的速率限制對于具有不同用戶角色的應用程序特別關鍵，它確保特權用戶獲得優(yōu)先訪問的同時保持系統(tǒng)的完整性和性能。

不受限制的 API 訪問和增加暴露的 API(無適當控制)可能導致各種安全問題。

前 10 大 API 安全威脅中有 2 個與不受限制的訪問相關:

• 不受限制的資源消耗與分布式拒絕服務(DDoS)攻擊相關。攻擊者發(fā)起并發(fā)請求，過載流量并影響 API 響應性。如果 API 缺乏針對客戶端交互或資源使用的限制，它們會不堪重負。精心設計的 API 請求，包括特定參數(shù)或批量操作，可以定位漏洞，響應指標可以進一步突出潛在的弱點。
• 不受限制地訪問敏感業(yè)務流程是利用 API 所依賴的業(yè)務模型，定位和破壞或利用敏感業(yè)務流程。一個例子是“程序化倒賣”，攻擊者編寫代碼來操縱票務銷售商的 API，在票務開售時購買許多票務以轉售。與列表中的其他安全威脅不同，這不是一個技術威脅，而是一個業(yè)務威脅，妨礙真正的用戶購買產品。

找到一個提供速率限制的工具，這是防止惡意或意外濫用系統(tǒng)資源的關鍵措施。通過這個，您可以確保系統(tǒng)服務不會被大量請求壓垮。

根據(jù)特定端點或提出請求的用戶類型，可以應用不同的速率限制，允許定制訪問控制。這種細粒度的方法可以確保關鍵端點或特權用戶獲得優(yōu)先訪問，同時維持系統(tǒng)完整性和最佳的用戶體驗。

下面是一個例子，說明您的 API 網關工具可能如何應對 DDoS 攻擊。當這種情況發(fā)生時，API 網關可以通過兩種機制主動應對這些攻擊：

• 開發(fā)人員可以設置請求閾值來檢測潛在的 DDoS 攻擊并緩解這些問題。
• 它采用緩存機制，在正常使用和遭到攻擊期間減少后端負載，確保更快的響應并節(jié)省寶貴資源。

無處不在的安全威脅：數(shù)據(jù)驗證

數(shù)據(jù)驗證和清理在維持所處理信息的真實性和安全性方面發(fā)揮關鍵作用。

來自服務器端請求偽造(SSRF)的 API 威脅是巨大的。這發(fā)生在 API 獲取外部資源時沒有驗證用戶提供的 URL。這使攻擊者可以強制應用程序向意外目標發(fā)送定制請求，繞過防火墻或 VPN。OWASP 清楚地指出:

“更危險——現(xiàn)代技術如云提供商、Kubernetes 和 Docker 通過 HTTP 在可預測的、眾所周知的路徑上暴露管理和控制渠道。這些渠道很容易成為 SSRF 攻擊的目標?！?/p>

完全消除 SSRF 風險具有挑戰(zhàn)性。選擇保護措施需要在業(yè)務風險與運營需求之間取得平衡。選擇一個提供強大功能的網關，可以有效驗證輸入和輸出數(shù)據(jù)，并識別和阻止惡意內容。

在網絡威脅橫行的時代，在系統(tǒng)被入侵之前過濾掉潛在有害數(shù)據(jù)的機制無價之寶。這種主動方法可以保護應用程序并確保更安全的用戶體驗。

外部安全威脅：第三方風險

依賴第三方軟件或服務可能會引入未知的漏洞。在不安全使用 API 時，開發(fā)人員不會驗證他們正在將哪些端點集成到他們的應用程序中。這些第三方 API 可能缺乏保護我們上述威脅的安全配置，例如 TLS、認證和驗證。

將 API 網關日志和數(shù)據(jù)集成到例行安全評估中可以提供對系統(tǒng)當前狀態(tài)和潛在弱點的整體視圖。這些日志提供了關于流量模式、用戶交互和潛在紅旗的寶貴見解。

與此同時，應規(guī)定對 API 及其關聯(lián)環(huán)境進行定期漏洞評估。這些評估深入研究基礎架構，識別潛在風險和未打補丁的漏洞，并確保系統(tǒng)能夠抵御不斷發(fā)展的威脅。定期審核和漏洞評估可以建立一個強大的防線，不斷加強和更新系統(tǒng)的安全態(tài)勢。

被忽視的安全威脅：錯誤配置

錯誤配置的系統(tǒng)通常會被忽視，可能會無意中暴露敏感數(shù)據(jù)或功能。攻擊者偵察暴露的端點、缺乏安全補丁、缺乏標準(如 TLS 和 CORS)以及不安全的錯誤消息。正確的配置很重要，您的 API 網關工具應該承擔這一責任:

1. 加密和數(shù)據(jù)保護：例如，Edge Stack API 網關在所有 API 端點上實施 TLS，以確保傳輸中的數(shù)據(jù)免受攔截或竊聽。它還確保靜態(tài)數(shù)據(jù)被加密，為保護敏感信息添加了一個額外的安全層，即使在不主動傳輸時也是如此。
2. 錯誤處理和信息泄漏預防：開發(fā)人員應該能夠配置他們的工具來抑制可能為攻擊者提供系統(tǒng)信息的詳細錯誤消息。相反，它向用戶返回通用錯誤消息，限制信息暴露并防止惡意行為者的潛在利用途徑。
3. 持續(xù)更新和修補程序：選擇一個網關，它會不斷更新以解決安全漏洞，并及時實現(xiàn)已知漏洞的修補程序，從而減少攻擊者的機會窗口。
4. 日志記錄和監(jiān)控：開發(fā)人員應該設置他們的網關來記錄 API 請求和響應，維護一個全面記錄，這在事件后分析或取證調查期間可能是無價之寶。您的 DevOps 團隊可以主動監(jiān)控這些日志，以檢測可疑活動或異常情況，從而發(fā)出潛在安全威脅的信號。此外，您會想要一個與 SIEM 工具集成的工具。這統(tǒng)一了日志記錄和監(jiān)控，并利用 SIEM 解決方案提供的高級分析、關聯(lián)規(guī)則和實時警報，確保一個知情的安全態(tài)勢。

認真對待 API 安全

鑒于 API 的關鍵角色，API 安全在現(xiàn)代軟件生態(tài)系統(tǒng)中至關重要。雖然 API 為集成和擴展打開了廣闊的可能性，但它們也引入了一組必須精心解決的新安全挑戰(zhàn)。只要您整合了某種類型的 API 網關，就不會出錯，但這里有一些具體要考慮的事項:

• 它是云原生的嗎？云原生和 Kubernetes API 網關是為在云原生和 Kubernetes 環(huán)境中蓬勃發(fā)展而特意構建的。它們了解并采用容器編排平臺的動態(tài)特性。Kubernetes 原生 API 網關的一個例子是Edge Stack。
• 或者它是全面的嗎？更通用的 API 網關，如 Kong 或 Gloo，功能多樣，可以在各種環(huán)境中部署，包括 Kubernetes。但是，它們與 Kubernetes 的特定細微差別不固有地定制。它們需要更多的手動配置，但通常非常適應性強，并包括 API 開發(fā)生命周期中您可能會發(fā)現(xiàn)方便的其他套件工具。全面的解決方案可能不會提供與以 Kubernetes 為中心的對應物相同級別的自動服務發(fā)現(xiàn)、負載平衡和動態(tài)路由，這可能需要更多的手動管理。
• 開源還是商業(yè)？有各種開源選項可以嘗試，包括 KrakenD 開源 API 網關、Emissary Ingress、Tyk 的開源選項或 Apache APISIX。開源選項非常適合試用，但不總是具有良好維護的商業(yè)選項的支持和可擴展性。

無論您選擇哪種工具，請確保您獲得的 API 網關工具都會細致地解決這些問題。認識到 API 所伴隨的漏洞，并采用像 API 網關這樣的工具來抵制潛在的威脅和加強防御變得至關重要。

通過優(yōu)先考慮 API 安全，組織可以保護其數(shù)字資產并在用戶基礎中培育信任，確?？沙掷m(xù)增長和技術創(chuàng)新。有關哪種 API 網關工具最適合您的團隊的更多信息，請下載Ambassador Labs 的 API 購買指南。