當(dāng)今社會已進入一個信息廣泛互聯(lián)和共享的時代，API技術(shù)逐漸成為了現(xiàn)代數(shù)字業(yè)務(wù)環(huán)境的基礎(chǔ)組成，也是企業(yè)數(shù)字化轉(zhuǎn)型發(fā)展戰(zhàn)略實現(xiàn)的核心要素。幾乎所有的企業(yè)都依賴API進行服務(wù)連接、傳輸數(shù)據(jù)和控制系統(tǒng)。然而，API的爆炸性應(yīng)用也極大地擴展了企業(yè)的攻擊面，增加了企業(yè)對API安全性的需求。
API安全的現(xiàn)狀
Salt Security是一家API安全公司，它提供了一個整體保護平臺來防止API攻擊，并使用機器學(xué)習(xí)和AI來自動連續(xù)地識別和保護API。根據(jù)Salt Security2022年最新發(fā)布的《API安全趨勢調(diào)查報告》數(shù)據(jù)顯示：
● 2022年，平均每個受訪企業(yè)的API數(shù)量較去年增長82%。同時，惡意API流量占比約為2.1%，比去年激增117%；
● API攻擊正在引發(fā)嚴(yán)重的安全問題，有94%的受訪者表示他們在過去一年內(nèi)遇到過API安全問題；
● 近一半(47%)的受訪者表示，他們在企業(yè)應(yīng)用的API中檢測出安全漏洞;38%的受訪企業(yè)遭遇過API引發(fā)的身份安全問題，31%的受訪企業(yè)遭遇過API引發(fā)的敏感數(shù)據(jù)泄露和隱私安全事件；
● 40%的受訪者表示將努力解決API應(yīng)用安全問題，但只有11%的受訪者表示，目前已經(jīng)使用了針對性技術(shù)來進行API安全測試和保護工作。
以上研究結(jié)果表明，有很多企業(yè)還沒有對API面臨的安全威脅保持足夠的重視。但實際上，它們可能難以承受自己的商譽和誠信受到API安全事件帶來的損害。因此，所有企業(yè)都需要努力解決API的安全問題，確保對網(wǎng)絡(luò)中最常見和最嚴(yán)重的API安全威脅進行補救。
API安全風(fēng)險與防護建議
API安全不僅僅是修復(fù)單個漏洞的問題。相反，它需要IT團隊的全面關(guān)注。他們必須從更廣泛的角度解決API網(wǎng)絡(luò)安全缺口。任何API中的某一個安全問題都可能導(dǎo)致不必要的后果。 以下整理了一些最危險的API安全風(fēng)險和防護建議。
風(fēng)險一 影子API、僵尸API
影子API是目前API安全中最為突出的問題，由于API的使用率激增，企業(yè)往往無法全部跟蹤管理，因此，一些API無法及時進行維護更新，從而成為了被惡意黑客公開利用的漏洞。
與影子API類似，僵尸API對組織來說也是一個巨大的安全風(fēng)險，其通常指的是舊的、很少使用的API版本。由于僵尸API很少得到安全團隊的注意，所以也給了犯罪分子惡意利用的可乘之機。
防護建議
及時維護更新API庫存表可以盡可能減少影子API或僵尸API的存在。為此，組織必須要求IT團隊跟蹤和監(jiān)視所有正在運行的API，以查找未解決的漏洞、故障或錯誤配置。組織還可以利用自動化API安全工具(如AppTrana)進行API庫存跟蹤。此外，所有開發(fā)人員和相關(guān)人員都應(yīng)該確保所有API都有規(guī)范的文檔進行說明和映射。
風(fēng)險二 不安全的資源展示
一些API需要向客戶端顯示可用資源列表以供使用者及時了解。該列表可能包括“用戶”或“小部件”等元素，當(dāng)通過瀏覽器查看時，這些元素會以有組織的“分頁”(paginated)方式呈現(xiàn)。雖然這聽起來很有幫助，但任何展示資產(chǎn)信息(explicit information，如用戶的PII數(shù)據(jù)和資源列表)的API都容易遭受來自攻擊者的數(shù)據(jù)抓取，并從中提取敏感信息，例如受影響的web應(yīng)用程序使用情況、客戶電子郵件列表等等。
防護建議
可以限制展示分頁和資源列表的顯示，以避免數(shù)據(jù)被惡意抓取。例如為查看特定資源的API調(diào)用指定一個時間段。或者，為用戶設(shè)置API訪問密鑰，并限制API密鑰可能被使用的次數(shù)，超過次數(shù)將撤銷訪問并阻止API連接。
風(fēng)險三 未經(jīng)身份驗證的API
很多企業(yè)中存在大量歷史遺留應(yīng)用程序，因此，使用API而不進行身份驗證是目前很常見的現(xiàn)象。這些未經(jīng)身份驗證的API一旦公開暴露，就會對企業(yè)的應(yīng)用系統(tǒng)安全構(gòu)成威脅。雖然如何管理遺留API本身就是一種風(fēng)險，但讓未經(jīng)身份驗證的API獲取敏感數(shù)據(jù)(如PII)對于企業(yè)將是一個更大的安全隱患，甚至?xí)a(chǎn)生法規(guī)遵從和合規(guī)性方面的問題。
防護建議
強制進行API身份驗證，以防止未經(jīng)請求的API訪問敏感數(shù)據(jù)資源。雖然它可能不是一個完善的解決方案，但實現(xiàn)身份驗證可以控制API的訪問范圍，也能幫助IT管理人員在惡意訪問嘗試的情況下識別出訪問入口點。IT團隊還應(yīng)該定期進行API檢查，以確保足夠的API安全性，特別是在升級遺留應(yīng)用程序或報廢與這些API相關(guān)的老舊設(shè)備時。
風(fēng)險四 未經(jīng)授權(quán)的API
對所有API進行強制身份驗證本身并非一個完善的、有包容性的解決方案。安全團隊還應(yīng)該實現(xiàn)對API的授權(quán)訪問管理，以將安全風(fēng)險降至最低。使用經(jīng)過身份驗證但未經(jīng)授權(quán)的API是IT團隊經(jīng)常難以解決的固有API安全風(fēng)險。攻擊者可以通過各種方法(例如枚舉用戶標(biāo)識符)獲得經(jīng)過身份驗證的訪問，而不考慮擬攻擊用戶的權(quán)限級別，從而大量利用此類未經(jīng)合理授權(quán)的API。
防護建議
應(yīng)用程序開發(fā)人員經(jīng)常忽略對API進行合理授權(quán)，而經(jīng)過身份驗證的用戶就可以對API執(zhí)行任何預(yù)期的操作。因此，防止這種未經(jīng)授權(quán)的API訪問需要開發(fā)人員實現(xiàn)安全檢查，例如用戶ID或創(chuàng)建訪問控制列表，以限制通過身份驗證的用戶訪問不屬于他們的API數(shù)據(jù)。
風(fēng)險五 公開暴露的API密鑰
當(dāng)不同的應(yīng)用系統(tǒng)進行交互時，就需要通過API進行連接，這時候就需要一個密鑰進行安全性確認。開發(fā)人員應(yīng)該在整合這些應(yīng)用時，保證密鑰的安全性。但是很多開發(fā)人員為了工作方便，會在開發(fā)過程中將API認證密鑰直接嵌入到API中，但是之后也未及時刪除。一旦這個API密鑰被攻擊者查詢獲得，就能夠以關(guān)聯(lián)合法用戶的身份，進行各種非法操作。
防護建議
一般的做法應(yīng)該是只將密鑰暴露給指定的用戶。而從長遠來看，在開發(fā)階段就有效規(guī)范安全管理流程可以防止密鑰泄露和惡意抓取等API應(yīng)用威脅。
風(fēng)險六 API監(jiān)控不足
API監(jiān)控不足也可歸因于企業(yè)對API應(yīng)用安全性的忽視。當(dāng)API應(yīng)用缺少監(jiān)控時，會給潛在的攻擊者足夠的時間來建立對受損API的訪問并保持長期連接。這種隱形攻擊可能導(dǎo)致企業(yè)財產(chǎn)、商譽和數(shù)據(jù)資產(chǎn)的損失。根據(jù)OWASP的說法，組織檢測修復(fù)漏洞的平均時間約為200多天，因此IT人員需要在更短時間里發(fā)現(xiàn)API應(yīng)用的異常情況。
防護建議
企業(yè)要對API的應(yīng)用安全問題提高警惕。常規(guī)的API日志記錄不應(yīng)該局限于API請求。相反地，它必須涵蓋用戶行為分析并存儲大約一年的日志。組織必須定期開展API安全應(yīng)用審計，以確保足夠的API日志記錄和安全的日志存儲。
風(fēng)險七 應(yīng)用服務(wù)器安全性差
不安全的應(yīng)用服務(wù)器可能泄漏大量數(shù)據(jù)，不安全或配置錯誤的API應(yīng)用也反映出組織存在巨大的網(wǎng)絡(luò)安全缺口。當(dāng)開發(fā)人員未能部署基本的安全措施(如實現(xiàn)HTTPS通信)時，通常會出現(xiàn)此問題。不幸的是，許多web應(yīng)用程序仍然支持HTTP通信，這樣就會輕易暴露API密鑰等敏感數(shù)據(jù)。由于web瀏覽器并不直接處理API，像HTTPS-redirect(重定向)這樣的特性在這里不能受到任何保護。
防護建議
采用HTTPS-only-like方法是防止應(yīng)用服務(wù)意外數(shù)據(jù)暴露的關(guān)鍵。開發(fā)人員還可以通過部署負載均衡設(shè)備，實現(xiàn)利用SSL來加密數(shù)據(jù)和阻止不安全的HTTP請求。
參考資料
https://latesthackingnews.com/2022/12/21/are-these-7-security-gaps-in-your-apis/
《API安全趨勢調(diào)查報告》：https://salt.security/api-security-trends
來源：安全牛
