萬物互聯(lián)的數(shù)字時代，API 在應(yīng)用環(huán)境中變得越來越普遍，通過 API 可以快速構(gòu)建產(chǎn)品和服務(wù)，并迅速響應(yīng)客戶的需求，它已成為數(shù)字化企業(yè)的必備技能。尤其在后疫情時代，遠程辦公、線上教學(xué)等線上應(yīng)用迅速發(fā)展，作為一種能夠支撐線上應(yīng)用連接和數(shù)據(jù)傳輸重任的輕量化技術(shù)，API 已無處不在。與此同時，API 承載著企業(yè)核心業(yè)務(wù)邏輯以及敏感數(shù)據(jù)，因此成為網(wǎng)絡(luò)犯罪分子的重點攻擊目標。

API 安全事件頻發(fā)

近年來，由于API的高速發(fā)展以及業(yè)務(wù)增速和安全的不對位，因此API安全問題導(dǎo)致的數(shù)據(jù)泄露事件頻發(fā)。例如：

• 2021年4月Facebook5億用戶數(shù)據(jù)泄漏，根據(jù)暗網(wǎng)上公布的數(shù)據(jù)截圖，涉及到用戶的昵稱，郵箱，電話，家庭住址的信息判斷，為業(yè)務(wù)接口泄漏。
• 2021年6月，根據(jù)裁判文書網(wǎng)公開的判決案例顯示，犯罪嫌疑人逯某通過某寶業(yè)務(wù)接口開發(fā)的爬蟲軟件獲取了用戶id，昵稱，電話號碼等信息11億條。
• 2021年12月，國內(nèi)某證券公司的客戶信息數(shù)據(jù)，包括：用戶姓名、手機號、開戶時間、交易情況等敏感數(shù)據(jù)，以每日1萬多條的量級在數(shù)據(jù)交易平臺被售賣。經(jīng)驗證分析，證實為內(nèi)部系統(tǒng)數(shù)據(jù)API管控疏忽導(dǎo)致。

至于為何企業(yè)會持續(xù)不斷的發(fā)生類似問題？首先，企業(yè)的業(yè)務(wù)迭代速度越來越快，對線上業(yè)務(wù)的API管理難度增加；此外，對于企業(yè)的安全團隊來說，線上業(yè)務(wù)的風(fēng)險管理不單單是技術(shù)問題，需要業(yè)務(wù)方有足夠的主動配合意愿；另外，當(dāng)黑灰產(chǎn)已經(jīng)開始以業(yè)務(wù)風(fēng)險為主要攻擊平面的時候，企業(yè)對業(yè)務(wù)安全的意識不夠，需要時間來轉(zhuǎn)換。

API 安全風(fēng)險加劇 

據(jù)《2021年中國互聯(lián)網(wǎng)安全報告》數(shù)據(jù)顯示，2021年針對API業(yè)務(wù)的攻擊達到147.98億次，同比增長超過200%。此外，針對API業(yè)務(wù)的攻擊手段類型整體趨于多樣化。 

Gartner 曾預(yù)測:“到 2022 年，API 濫用將從原本頻率較低的攻擊類型變?yōu)閷?dǎo)致企業(yè) Web 應(yīng)用程序數(shù)據(jù)泄露的最常見攻擊媒介。” 

果不其然，根據(jù)研究部門 Salt Labs 發(fā)布的《2022年第一季度 API 安全狀況報告》顯示，過去一年，惡意 API 流量增加了 681%，有 95% 的企業(yè)都經(jīng)歷了 API 安全事件，而且大多數(shù)企業(yè)并沒有準備好應(yīng)對這些挑戰(zhàn)，還有 34% 的企業(yè)沒有 API 安全策略。

Karma 情報平臺通過捕捉到的 API 自動化攻擊工具和攻擊流量對近期的API安全風(fēng)險態(tài)勢進行了分析：

• 網(wǎng)絡(luò)攻擊持續(xù)高發(fā)，API攻擊量月均超25萬；
• 營銷作弊仍是主要的API攻擊場景，數(shù)字藏品被攻擊熱度依舊高漲；
• 惡意爬蟲針對API進行破解和偽造，房源、招聘等信息成重點爬取對象；
• 利用API非法竊取數(shù)據(jù)，數(shù)字政務(wù)成為重點攻擊目標。

API存在安全缺陷是導(dǎo)致API攻擊的主要原因。據(jù)永安在線《API安全研究報告》顯示，未授權(quán)訪問、允許弱密碼、錯誤提示不合理以及云服務(wù)配置錯誤是近期需要引起重視的四類API安全缺陷。

其實，API漏洞與Web漏洞大同小異，API 調(diào)用能更容易、更快速地實現(xiàn)自動化，這是其設(shè)計使然，可也是一把雙刃劍，不但方便了開發(fā)人員，同時也方便了攻擊者。

API 安全性建議

Akamai 在其發(fā)布的《互聯(lián)網(wǎng)現(xiàn)狀/安全性》報告中建議了幾項 API 安全性的最佳做法:  

1. 發(fā)現(xiàn)您的 API 并對它們進行逐一盤點跟蹤。許多企業(yè)都遭遇過他們毫不知情的 API 所引發(fā)的事件。因此，了解 API 的位置及其用途至關(guān)重要。與此相關(guān)的還有企業(yè)使用的外部 API。這些 API 也需要得到識別和保護，或者至少被登記為潛在的風(fēng)險項目并得到評估。

2. 一旦確定所有 API 的位置，您就要對它們進行測試并了解其中存在哪些漏洞。這不僅需要測試工具和扎實的開發(fā)人員培訓(xùn)，也需要與現(xiàn)有安全團隊緊密合作。另外還需要針對風(fēng)險承受能力進行探討，并制定計劃以盡早修復(fù)漏洞。首先確定是否存在硬編碼密鑰、邏輯調(diào)用，并了解 API 流量是否會受到冒充攻擊的影響。還有一個好辦法就是掃描存儲和代碼庫以查找可用于破壞 API 或與其相關(guān)的任何內(nèi)容的密鑰。

3. 在開發(fā)和發(fā)布期間，充分利用現(xiàn)有的 WAF 基礎(chǔ)架構(gòu)、任何身份管理和數(shù)據(jù)保護解決方案，以及任何專門的 API 安全工具。此外，確保 API 安全性是一項長期工作，而不是開發(fā)過程中的一次性任務(wù)。新的漏洞和攻擊源源不斷，一次性檢查只會讓攻擊面暴露在風(fēng)險之中。

4. 在 API 策略方面，盡量避免為每種 API 使用唯一的策略，而是偏向于可以重用的一攬子策略。此外，不要將策略直接編碼到需要保護的 API 中。這樣做違反了職責(zé)分離機制，增加了不必要的復(fù)雜性，也額外加重了維護代碼的人員的管理負擔(dān)，并造成安全團隊缺乏可見性。有一條有效的經(jīng)驗法則，就是將任何資源的默認訪問級別設(shè)置為空值或拒絕。這會強制執(zhí)行最小特權(quán)，并使身份驗證成為一項持續(xù)要求。

5. 在某種層面上，API 開發(fā)需要各種利益相關(guān)者的參與。其中包括開發(fā)團隊、網(wǎng)絡(luò)與安全運營團隊、身份相關(guān)團隊(如果他們不屬于運營團隊)、風(fēng)險管理師、安全架構(gòu)師，以及法律/合規(guī)團隊(以確保產(chǎn)品遵守所有治理和監(jiān)管法律)。

如今，針對API的攻擊逐漸成為惡意攻擊者的首選，將有越來越多的攻擊者利用API竊取敏感數(shù)據(jù)并進行業(yè)務(wù)欺詐，API作為數(shù)字時代應(yīng)用服務(wù)化的關(guān)鍵技術(shù)支撐，為其構(gòu)建健全的安全防護體系已勢在必行。?