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