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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

被忽視的安全威脅：錯(cuò)誤配置

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

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

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

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

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

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