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

譯自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 漏洞的起點(diǎn)。

自 2019 年以來，該組織還制定了一個針對 API 安全威脅的前 10 名，以提高人們對 API 安全的認(rèn)識，并提供解決最緊迫威脅的指導(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)安全保護(hù)，它們可能被利用來泄露敏感信息、繞過安全控制或者甚至操縱基礎(chǔ)系統(tǒng)。

OWASP API 安全項(xiàng)目在 7 月發(fā)布了新的前10 大 API 安全威脅。讓我們回顧這個列表的要點(diǎn)，以及 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 必須驗(yàn)證用戶對這些對象的操作權(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 端點(diǎn)來利用損壞的函數(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)險。

永恒的安全威脅：認(rèn)證

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

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

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

無論您選擇哪個 API 網(wǎng)關(guān)，請確保它可以根據(jù)經(jīng)過身份驗(yàn)證的用戶執(zhí)行速率限制。這是一個關(guān)鍵功能，因?yàn)樗梢酝ㄟ^限制用戶可以提出的請求的頻率來防止?jié)撛诘臑E用。例如，通過將速率限制與特定的經(jīng)過身份驗(yàn)證的配置文件相關(guān)聯(lián)，Edge Stack 等選項(xiàng)可以確保系統(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 缺乏針對客戶端交互或資源使用的限制，它們會不堪重負(fù)。精心設(shè)計(jì)的 API 請求，包括特定參數(shù)或批量操作，可以定位漏洞，響應(yīng)指標(biāo)可以進(jìn)一步突出潛在的弱點(diǎn)。
• 不受限制地訪問敏感業(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ù)特定端點(diǎn)或提出請求的用戶類型，可以應(yīng)用不同的速率限制，允許定制訪問控制。這種細(xì)粒度的方法可以確保關(guān)鍵端點(diǎn)或特權(quán)用戶獲得優(yōu)先訪問，同時維持系統(tǒng)完整性和最佳的用戶體驗(yàn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

認(rèn)真對待 API 安全

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

• 它是云原生的嗎？云原生和 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 的特定細(xì)微差別不固有地定制。它們需要更多的手動配置，但通常非常適應(yīng)性強(qiáng)，并包括 API 開發(fā)生命周期中您可能會發(fā)現(xiàn)方便的其他套件工具。全面的解決方案可能不會提供與以 Kubernetes 為中心的對應(yīng)物相同級別的自動服務(wù)發(fā)現(xiàn)、負(fù)載平衡和動態(tài)路由，這可能需要更多的手動管理。
• 開源還是商業(yè)？有各種開源選項(xiàng)可以嘗試，包括 KrakenD 開源 API 網(wǎng)關(guān)、Emissary Ingress、Tyk 的開源選項(xiàng)或 Apache APISIX。開源選項(xiàng)非常適合試用，但不總是具有良好維護(hù)的商業(yè)選項(xiàng)的支持和可擴(kuò)展性。

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

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