API十大安全威脅解析及API網(wǎng)關(guān)的安全防護。

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

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

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

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

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

最大的安全威脅：授權(quán)

損壞的授權(quán)已經(jīng)成為應(yīng)用程序正在承受的最大 API 安全威脅。2023 年名單中前 10 大 API 安全威脅中有 3 個與授權(quán)相關(guān):

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

永恒的安全威脅：認證

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

外部安全威脅：第三方風(fēng)險

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

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

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

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

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

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

認真對待 API 安全

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

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

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

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