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