《威脅獵人:API安全發展白皮書(2023)(49頁).pdf》由會員分享,可在線閱讀,更多相關《威脅獵人:API安全發展白皮書(2023)(49頁).pdf(49頁珍藏版)》請在三個皮匠報告上搜索。
1、 版版 權權 聲聲 明明 本報告版權屬于深圳永安在線科技有限公司、中國信本報告版權屬于深圳永安在線科技有限公司、中國信息通信研究院云計算與大數據研究所,并受法律保護。轉息通信研究院云計算與大數據研究所,并受法律保護。轉載、摘編或利用其它方式使用本報告文字或者觀點的,應載、摘編或利用其它方式使用本報告文字或者觀點的,應注明注明“來源:深圳永安在線科技有限公司、中國信息通信研來源:深圳永安在線科技有限公司、中國信息通信研究院云計算與大數據研究所究院云計算與大數據研究所”。違反上述聲明者,編者將追。違反上述聲明者,編者將追究其相關法律責任。究其相關法律責任。參參 編編 人人 員員 畢裕、黃巍、吳越林
2、、李憶晨、衛斌、郭雪、孔松目目 錄錄 一、API 安全概述.1(一)API 已成為數字化轉型的重要抓手,安全監管日趨嚴格.1(二)API 屢受攻擊,安全治理存在眾多難點.3 二、API 爆發式增長催生新的安全挑戰.5(一)API 攻擊趨勢:新型攻擊手段頻現且難以防范.5 1.攻擊手段多樣化.5 2.攻擊途徑隱蔽化.7 3.攻擊場景自動化.8(二)API 安全挑戰:API 安全已成為網絡安全的最大威脅之一.9 1.API 資產缺乏可見性,或將帶來無法量化的風險.9 2.API 攻擊面不斷變化,企業難以管理和把控.11 3.現有防護體系難以對 API 風險進行有效識別.12 4.API 安全治理成
3、企業數據安全合規的必要舉措.14 5.企業跨部門協同存難題,API 安全全生命周期治理難實現.15 三、API 安全防護體系建設思路.16(一)總述.16(二)基于 API 生命周期構建安全防護模型.16 1.規劃階段:引入威脅建模理論.17 2.開發階段:加強安全開發建設,引入安全工具.19 3.測試階段:使用 AST 類工具進行自動化漏洞測試,提高覆蓋率.21 4.部署階段:確保 API 的部署和配置的安全性.22 5.運維階段:利用工具及時感知 API 攻擊威脅.23 6.下線階段:及時下線僵尸影子 API.25(三)API 安全閉環管理要求和建議.26 1.Identify:構建可持續
4、的識別能力.27 2.Protect:構建實時的防護能力.29 3.Detect:構建全面的檢測能力.30 4.Respond:構建高效的響應能力.32 5.Recover:構建閉環式的修復能力.33 四、API 安全未來發展趨勢展望.34 附錄 1 2022 年全球 API 攻擊重要事件.36 附錄 2 API 安全最佳實踐.39(一)金融行業.39(二)互聯網行業.40(三)傳統數字化.41 圖圖 目目 錄錄 圖 1 API 生命周期安全管理模型.17 圖 2 API 安全閉環管理.26 圖 3 某互聯網企業業務請求量.31 表表 目目 錄錄 表 1 API 安全檢查表及最佳實踐.19 表
5、 2 API 安全編碼和開發規范.20 API 安全發展白皮書(2023)1 一、API 安全概述(一)(一)API 已成為數字化轉型的重要抓手,安全監管已成為數字化轉型的重要抓手,安全監管日趨嚴格日趨嚴格 API 指應用程序接口(Application Programming Interface)。中華人民共和國國家標準信息安全技術術語(GB/T25069-2022)將其定義為“一組預先定義好的功能,開發者可通過該功能(或功能的組合)便捷地訪問相關服務,而無需關注服務的設計與實現”。應用程序接口作為促進數據流通的重要技術,不僅可以幫助企業建立與客戶溝通的渠道,還承擔著不同復雜系統環境、組織機
6、構之間的數據交互、傳輸的任務。API 安全指對應用程序接口的完整性進行有效的防護。API 安全通常包括接口的信息安全、數據安全以及應用安全。API 成為企業數字化轉型的重要抓手。自新冠疫情以來,各企業及機構紛紛加快數字化轉型的步伐。國家互聯網信息辦公室發布的數字中國發展報告(2022 年)顯示,2022 年我國數字經濟規模達 50.2 萬億元,數字經濟成為穩增長促轉型的重要引擎。隨著企業將越來越多的數據和應用遷移至云端,API 也正成為企業成功數字化轉型的戰略重點之一。IDC 報告顯示,到 2021 年,超過 50%的全球2000 強企業,將用 API 開放生態系統完成其平均 1/3 的數字化
7、服務交互。開發、管理和保護 API 安全,將成為數字化時代下企業及機構需要重點考量的關鍵因素。云計算引爆 API 安全危機。隨著云計算、大數據、人工智能的蓬API 安全發展白皮書(2023)2 勃發展,越來越多的應用開發深度依賴于 API 之間的相互調用。與此同時,隨著全球云上業務快速發展,API 作為系統間的通信橋梁,也正成為攻擊者重點光顧的目標,其安全漏洞隨著調用量增多而暴露無遺。Gartner 在如何建立有效的 API 安全策略報告中預測,API 濫用將成為導致企業 Web 應用程序數據泄露的最常見攻擊媒介,到2024 年,API 濫用和相關數據泄露將幾乎翻倍。通過攻擊 API 來破壞信
8、息系統和竊取數據,已成為數字時代黑產活動最集中的方向之一。我國 API 相關監管逐漸清晰化,但針對不同領域的 API 安全攻防體系難以進行規?;涞?。2021 年 9 月 1 日,中華人民共和國數據安全法正式實施,為開展數據安全監管和保護工作提供了法律依據,對數據的有效監管實現了有法可依,并完善了網絡空間安全治理的法律體系。API 作為數據傳輸間的橋梁,應遵守相關法律進行安全監管。2020 年 2 月 13 日,中國人民銀行發布商業銀行應用程序接口安全管理規范(JR/T 01852020)金融行業標準,規定了商業銀行應用程序接口的類型與安全級別、安全設計、安全部署、安全集成、安全運維、服務終止
9、與系統下線、安全管理等安全技術與安全保障要求。我國傳統產業規模龐大,數字化進程呈現行業細分的特點,不同垂直領域的安全需求差異較大。數據開放共享過程中涉及個人隱私、商業機密等數據的安全保護制度不夠完善、防護技術亟待提升?,F有 API 相關標準和 API 安全攻防體系難以實現規?;瘡椭?,導致數據質量規范標準、數據價值量化標準匱乏,因此發展難度也更高。API 安全發展白皮書(2023)3 (二)(二)API 屢受攻擊,屢受攻擊,安全治理存在眾多難點安全治理存在眾多難點 國際國內 API 遭受攻擊的事件屢見不鮮,已引發廣泛關注。受經濟利益驅動的攻擊者對各個行業的暴露 API 進行廣泛攻擊,非法竊取隱私
10、數據,造成嚴重社會影響。國際方面,2023 年 1 月 19 日,美國某運營商暴露的 API 遭到攻擊,導致超三千萬名用戶的姓名、賬單地址、電子郵件、電話號碼、出生日期被泄露。2023 年 1 月,數十家全球汽車制造商生產的車輛和車聯網服務被披露存在眾多 API 安全缺陷,攻擊者可利用 API 漏洞非法竊取車輛行駛路線信息。2022 年,美國某平臺網站上超五百萬賬戶的電話號碼和電子郵件地址遭泄露,而泄露數據是通過漏洞賞金計劃中披露的 API 漏洞收集的。國內方面,2020 年,某社交平臺 API 遭到爬蟲攻擊,導致超 5 億用戶信息在暗網出售。2020 年 11 月,某企業被曝出有內部人員有償
11、租借員工賬號,導致數十萬條公民個人信息被泄露事件。被泄露的信息中包括地址、姓名、電話等信息。2021 年,某企業的 API 遭到爬蟲攻擊,涉及用戶賬號、昵稱、手機號、商品等超億條信息。新型 API 攻擊手段頻現,攻擊手段呈多樣化、隱蔽化發展。隨著API 訪問環境的愈發開放、API 數量的極速攀升,攻擊者正開發出更多更先進的攻擊工具和方法對暴露在外的 API 加以利用,早期防護技術已經無法滿足現有安全問題的防護需求。新型 API 攻擊主要呈現兩個趨勢。第一是攻擊手段多樣化。面對受害者的防御策略,攻擊者會同時采用多種攻擊方法,形成“地毯式轟炸攻擊”模式。針對 API 的API 安全發展白皮書(20
12、23)4 新型安全威脅包括注入攻擊、內容篡改、參數篡改等。在新型攻擊手段下,傳統 API 安全網關提供的身份認證、權限管控、速率限制、請求內容校驗等安全機制逐漸失靈。第二是攻擊途徑隱蔽化。合法應用程序所使用的加密通道、端口和協議也為攻擊者提供了掩蓋其足跡的方法。對于安全專業人員而言,從經由 API 接口傳入和傳出的眾多HTTPS 請求中攔截、篩選和分析可疑流量則變得更加麻煩。API 安全治理存在多個難點,傳統 API 體系問題日趨明顯。為了適應數字化進程的快速發展,政府、企業都會開放大量的 API,由此造成的數據安全風險敞口,傳統的 API 安全體系并不能完全應對解決。傳統 API 安全體系主
13、要存在四大問題。第一是 API 資產難以進行全面梳理。API 資產盤點仍然停留在主機、服務、端口維度,無法清晰盤點所有 API 接口,以及可以輸出敏感數據的 API 接口。第二是難以針對 API 接口進行全面的脆弱性評估。API 資產數量龐大且其業務相關性強、迭代速度快,安全運營人員難以對 API 遺留的安全漏洞進行安全性評估。第三是針對 API 接口的威脅檢測機制不完善。當前普遍缺乏對 API 的細粒度檢測,只能基于已知特征的 API、勒索軟件、木馬、病毒進行威脅監測,無法實時發現數據泄露以及針對 API接口特征的攻擊。第四是發生 API 攻擊事件后的事后追溯難。企業針對 API 的日志管理
14、普遍存在分散存儲、日志記錄不全、格式不規范等問題,一旦發生網絡故障或安全事件時,無法在短時間內定位責任人和泄露路徑。API 安全發展白皮書(2023)5 二、API 爆發式增長催生新的安全挑戰 (一)(一)API 攻擊趨攻擊趨勢:新型攻擊手段頻現且難以防范勢:新型攻擊手段頻現且難以防范 數字化時代與線上化趨勢下,API 作為連接不同應用和系統的橋梁,正迅速成為現代企業的核心組件。API 的爆發式增長在為企業提供了更強大、靈活的數據交換和功能擴展能力、創造更多商業機會的同時,也帶來了新的安全挑戰。API 接口數量的暴增與其安全發展的不匹配,使其成為惡意攻擊的首選目標,API 安全問題受到廣泛關注
15、。1.攻擊手段多樣化攻擊手段多樣化 API 是企業數字化轉型的關鍵組成部分,攻擊者可以利用各種不同的手段攻擊 API 并竊取敏感數據或者干擾企業的業務流程。常見的API 攻擊手段包括但不限于:1.1 拒絕服務攻擊(Denial of Service,DoS)。攻擊者通過發送大量占用計算資源的請求,例如大文件下載、高負荷的搜索請求等,使得 API 服務器無法分辨并響應合法請求,從而導致 API 服務器資源耗盡,服務不可用。1.2 注入漏洞利用攻擊。攻擊者通過在API請求中注入惡意代碼,以獲取未授權的數據或執行未授權的操作。例如,攻擊者通過在 API請求中注入 SQL 注入代碼的方式,獲取數據庫中
16、的敏感信息。1.3 未授權漏洞利用攻擊。系統對用戶的訪問控制無限制,攻擊者可直接獲取未授權的數據或執行未授權的操作。例如,攻擊者可在API 請求中使用未經過授權的密鑰進行 API 調用,從而獲取或修改數API 安全發展白皮書(2023)6 據,導致信息泄露,甚至破壞系統功能。1.4 安全配置漏洞利用攻擊。攻擊者通過發現 API 服務器未正確配置安全措施,利用錯誤配置發起漏洞攻擊。例如,攻擊者可以通過訪問 API 服務器的管理接口修改 API 的安全配置,以繞過安全措施獲取敏感數據。1.5 越權訪問漏洞利用攻擊。系統對用戶的訪問控制限制不正確,攻擊者可直接獲取超出授權的數據或執行超出授權的操作。
17、越權訪問包括水平越權攻擊和垂直越權攻擊兩種形式。水平越權攻擊是指攻擊者通過利用 API 的漏洞,獲取其他用戶或角色擁有的權限范圍。垂直越權攻擊是指攻擊者通過利用 API 的漏洞,獲取比其本身權限更高的權限。例如,攻擊者可能會通過利用該 API 漏洞,通過普通用戶的憑證來執行管理員級別的操作。1.6 參數遍歷攻擊。攻擊者通過修改 API 請求參數來遍歷 API 中的文件或目錄,獲取未授權的數據或執行未授權的操作。例如,攻擊者可通過修改 API 請求參數,對 API 的敏感數據或服務器上的文件進行非法訪問。1.7 明文傳輸利用攻擊。攻擊者通過截獲 API 請求,以獲取未加密的敏感信息。1.8 代碼
18、設計漏洞攻擊。攻擊者利用目標 API 中的代碼設計漏洞進行攻擊。這些漏洞通常是由于編碼或設計錯誤而導致的,可能涉及不安全的數據處理、緩沖區溢出、格式字符串漏洞、邏輯錯誤、錯誤API 安全發展白皮書(2023)7 處理等。例如,某些 API 可能會設計特定數據類型的處理方式,這可能引發攻擊者利用該設計漏洞構造特定類型的惡意數據,從而導致API 崩潰或執行惡意代碼。1.9 第三方組件漏洞利用攻擊。許多應用程序和系統都使用第三方組件,例如開源庫、框架和插件,以便快速構建和部署應用程序。此類組件通常由其他開發者編寫和維護,在開發過程中可能存在開放性的安全漏洞。攻擊者可以利用安全漏洞進行 API 攻擊。
19、例如,攻擊者可以利用已知的第三方組件漏洞,繞過 API 的安全措施并獲取系統權限。這種攻擊可能會導致數據泄露、拒絕服務等安全問題。2.攻擊途徑隱蔽化攻擊途徑隱蔽化 為了規避現有安全防護設備的檢測,提高攻擊成功率,越來越多的攻擊者會采用如下方式來隱蔽其攻擊途徑:2.1 使用代理服務器。攻擊者使用代理服務器隱藏真實 IP 地址和其他攻擊特征(如攻擊次數、攻擊頻率)。這可以使攻擊者更難被追蹤和識別,從而提高攻擊的成功率。2.2 濫用邏輯漏洞。攻擊者濫用 API 邏輯漏洞發起隱蔽攻擊,例如未授權訪問、越權訪問、過度的錯誤提示等。此類行為可能被認為是正常的系統操作,從而不會被管理員或安全人員察覺,更不會
20、引起警報。2.3 模擬真實用戶請求。攻擊者可以使用一些工具來模擬各種類型的真實用戶請求,包括 GET、POST、PUT、DELETE 等請求類型,API 安全發展白皮書(2023)8 也可以模擬多個用戶的流量,并使用分布式攻擊工具避免被識別。2.4 破解 API 密鑰。攻擊者可以嘗試破解 API 密鑰或偽造 API 密鑰,以此來繞過 API 的安全措施,如攻擊者可以使用字典庫來暴力破解 API 密鑰。2.5 重定向攻擊。攻擊者可以利用 API 中的重定向功能來跳過安全檢測、混淆或隱藏攻擊路徑。2.6 濫用 API 版本。API 舊版本可能存在漏洞或者安全問題,攻擊者可以利用此類問題進行攻擊。攻
21、擊者可嘗試使用較舊的 API 版本以便繞過最新版本的安全措施,或者利用最新版本中的漏洞來進行攻擊。3.攻擊場景自動化攻擊場景自動化 攻擊者對 API 進行自動化攻擊的主要目的是提高攻擊效率和成功率,同時降低攻擊成本和風險。通過自動化攻擊工具和腳本,攻擊者可以快速發現 API 漏洞,大量嘗試不同的攻擊方式和參數組合,并快速利用漏洞進行攻擊,從而避免人工操作的不穩定性和易出錯性。攻擊者針對 API 發起攻擊場景自動化的趨勢主要有以下方向:3.1 增加攻擊深度和復雜度。攻擊者傾向于組合多種不同的攻擊方法,實現更深入和復雜的攻擊。例如,在針對 API 的自動化攻擊中,攻擊者可能會結合使用掃描、爬蟲、滲
22、透測試等多種工具,以實現更廣泛和深度的攻擊。3.2 模塊化攻擊方式。攻擊者將攻擊過程分解成多個模塊,每個API 安全發展白皮書(2023)9 模塊都可以獨立完成特定的攻擊任務。這些模塊可以根據攻擊者需要進行靈活組裝,以快速完成攻擊工具的制作,使攻擊更高效。因此,攻擊者越來越傾向于使用模塊化的攻擊工具來發起針對 API 的攻擊行為。3.3 與 SaaS 攻擊平臺結合。攻擊者日益傾向于將自動化攻擊工具與 SaaS 攻擊平臺結合使用。例如攻擊者會使用 SaaS 化攻擊平臺進行自動化攻擊工具開發。SaaS 化攻擊平臺包括代理 IP 平臺、接碼平臺等,能夠為攻擊者提供更強大的攻擊工具和更高效的攻擊方法。
23、3.4 攻擊工具市場化。攻擊者將自動化攻擊工具的使用權出售給其他攻擊者,以獲取更高的收益。這些攻擊工具可以被打包成易于使用的軟件,稱為攻擊套件,并在地下黑市上出售。攻擊者甚至會為攻擊工具提供售后和更新服務,以保持工具的有效性。3.5 利用 AI 和機器學習技術進行攻擊。隨著 AI 和機器學習技術的迅速發展,攻擊者開始利用新技術實現自動化攻擊。例如,攻擊者可以利用 AI 技術自動生成攻擊代碼或規避安全防御措施。(二)(二)API 安全挑戰:安全挑戰:API 安全已成為網絡安全的最安全已成為網絡安全的最大威脅之一大威脅之一 1.API 資產缺乏可見性,或將帶來無法量化的風險資產缺乏可見性,或將帶來
24、無法量化的風險 隨著 API 的廣泛應用和數量的快速增長,企業可能面臨大量的API 資產,包括公開的、私有的和第三方的 API。這些 API 資產可能存在于企業的各種應用程序、云服務和微服務中,形成了龐雜的 APIAPI 安全發展白皮書(2023)10 暴露面。企業對于 API 暴露面的管理和保護是確保 API 安全的重要組成部分。然而,API 資產的發現卻是一個具有挑戰性的任務,企業進行 API 資產發現時可能遇到如下難點:1.1 API 資產的隱秘性。API 資產不會自主對外宣告,這使得它們很難被發現。內部系統的 API 資產、已靜默的 API 資產、東西向調用的 API 資產、第三方提供
25、的 API 資產等由于其隱蔽性將成為 API 資產發現過程中的盲區。1.2 API 資產的動態性。API 資產可能隨著業務需求而不斷變化,這將導致 API 資產變更愈加頻繁和快速,需要企業建立持續動態的API 發現流程。1.3 API 協議的多樣性?,F代 API 協議的多樣性使得 API 資產的發現更加具有挑戰性。例如,GraphQL 和 RPC 是兩種不同的 API 協議,它們具有不同的語法和語義,需要采用不同的方法進行資產發現。1.4 部署方式的復雜性。API 資產可能采用不同的部署方式,包括網關發布和私有化部署。網關發布通常是一種中心化的方式,它允許在單個入口點上集中所有 API。然而,
26、私有化部署則會使 API 資產更難以發現,因為它們可能被分散在多個環境中,包括本地網絡和云環境。此外,API 資產的創建者、使用者和管理者也可能不同,這也增加了 API 資產發現的難度。1.5 開發管理困難。企業的 API 資產累積以及開發管理規范化是逐步建設的過程。然而,在這個過程中,歷史建設或第三方創建的 APIAPI 安全發展白皮書(2023)11 資產可能無法被納入開發管理的范圍。另外開發管理規范也無法完全保證 API 開發過程的執行質量。這使得 API 資產的開發管理變得更加困難,也使得企業無法只從開發管理規范來實現 API 資產的可見性。1.6 組件引入的不確定性。在開發過程中,開
27、發人員可能會引入各種組件來加速開發進度、提高開發效率。這些組件包括但不限于第三方庫、框架、工具等。然而,這些組件包含許多 API 接口,這些 API接口可能被用于開發新的功能,或是作為開發現有功能的基礎,極有可能導致 API 資產失去管理,帶來一系列潛在風險,尤其是當這些組件由第三方提供的時候。1.7 程序框架的多樣性。API 資產往往使用不同的程序語言和框架,相應地就需要考慮不同的技術來進行 API 資產的發現。2.API 攻擊面不斷變化,企業難以管理和把控攻擊面不斷變化,企業難以管理和把控 企業在完成 API 資產梳理以后,需要對 API 資產所形成的攻擊面進行安全管理。而 API 攻擊面
28、的動態變化屬性導致了企業需要實時且可持續的安全管理手段。引發 API 攻擊面動態變化的原因有如下幾點:2.1 業務和技術變化。企業的業務需求和技術環境都在不斷變化。API 資產可能會隨著業務場景的變化而上線或下線,或者在技術架構的升級過程中發生變化。這些變化都會導致 API 的攻擊面發生動態變化。API 安全發展白皮書(2023)12 2.2 持續演化的安全威脅。安全威脅是一個不斷演化的過程,攻擊者會不斷發現新的漏洞和攻擊技術。即使在完成 API 資產梳理時沒有發現漏洞,但在之后的時間里,新的漏洞也可能會出現。攻擊技術的演化導致了 API 攻擊面的安全威脅的不確定性。2.3 第三方組件及服務。
29、企業在 API 開發部署過程中常使用第三方組件、容器以及第三方服務 API。這些組件、容器和服務 API 可能存在潛在的漏洞和安全問題,攻擊者可以利用它們來攻擊企業的 API系統。組件、容器及第三方服務 API 的安全問題不可控也導致了 API攻擊面的不可控?;谏鲜鰳I務、技術及安全威脅的不斷發展及演進,API 攻擊面的動態變化是不可避免的??蓪崟r持續發現 API 資產的狀態變化,感知 API 資產的未知漏洞和已知漏洞的修復狀態是企業實現 API 攻擊面管理的決定性技術要素。API 的攻擊面管理需要使用實時監測和自動化分析工具,幫助企業及時發現 API 資產的狀態變化,對 API 資產進行實時
30、的安全評估,從而針對問題資產快速做出反應并采取適當的管理和保護措施。3.現有防護體系難以對現有防護體系難以對 API 風險進行有效識別風險進行有效識別 攻擊者針對于 API 資產的攻擊手段存在多樣化、隱蔽化、自動化的趨勢,可以輕松突破企業對于 API 的限頻、限量及認證鑒權等基礎的防護手段。除此之外,大部分攻擊者利用 2023 OWASP API Security Top 10(對象級別授權失效、身份認證失效、對象屬性級別授權失效、API 安全發展白皮書(2023)13 資源消耗無限制、功能級別授權失效等)所列舉的邏輯漏洞進行攻擊,企業很難從流量中提取區別于正常用戶的特征信息,從而對攻擊進行阻
31、斷。針對 API 的邏輯攻擊,傳統的安全防護體系常常存在如下難點:3.1 攻擊流量無特征。攻擊者利用 API 邏輯漏洞時,通常會模擬正常的 API 請求,使用合法的 API 參數和協議。這使得企業現有安全設備(API 網關、WAF 等)難以區分攻擊流量和正常流量。因為攻擊流量與正常流量在協議和參數上并無明顯區別,傳統的基于規則的安全設備難以準確檢測和識別這種攻擊。3.2 攻擊行為跨越多個請求。API 邏輯漏洞通常涉及多個 API 請求上下文的交互,攻擊者通過多次請求的組合來實現攻擊目的。然而,現有安全設備難以理解攻擊的完整上下文,無法對多個 API 請求的關系和交互進行深入分析。這限制了它們在
32、識別和檢測 API 邏輯攻擊的準確性和有效性。3.3 缺失敏感數據的理解。API 邏輯攻擊通常涉及敏感數據的泄露、篡改或者未經授權的訪問。然而,現有安全設備主要關注網絡協議和數據格式,難以理解流量中傳遞的敏感數據的類型及內容,這導致它們無法對涉及敏感數據的惡意攻擊進行準確的檢測和識別。雖然 API 網關設備和 WAF 設備都開始引入人工智能學習算法來不斷分析攻擊者的攻擊方法和行為模式,并根據這些信息提煉出攻擊者的特征向量,自主地調整自身的規則和策略,但是在應對攻擊風險API 安全發展白皮書(2023)14 的過程中,仍存在三大問題難以解決。第一是導致誤報或漏報。AI 學習需要大量的數據集進行訓
33、練,如果數據集中存在偏差或噪聲,可能會導致誤報或漏報攻擊。同時,攻擊者也可以采用無特征的攻擊流量使 AI 學習無法歸納出特征向量或者歸納出錯誤的特征向量來規避檢測,導致設備的失效。第二是難以應對新型攻擊。盡管 AI 學習能夠識別歷史攻擊模式并對其進行預測和防范,但是對于新型攻擊模式,設備可能無法及時識別和防范,需要進行額外的人工干預和調整。第三是需要大量的計算資源。AI 學習需要大量的計算資源來訓練模型和執行實時檢測,這需要企業投入更多的成本來購買和維護高性能的設備和系統。除上述因素以外,企業內部系統以及東西向的流量也很難接入到WAF 設備及 API 網關設備,無法對上述系統或者流量進行 AP
34、I 風險的識別。因此,企業現有的防護體系難以有效應對 API 攻擊所帶來的新的挑戰。4.API 安全治理成企業數據安全合規的必要舉措安全治理成企業數據安全合規的必要舉措 對企業而言,圍繞數據的全生命周期,從數據采集、存儲、訪問、使用、銷毀構建完善的數據安全體系成為安全建設工作的重點。目前,大多數企業在數據采集、存儲、數據庫訪問方面做了比較全面的安全建設,在數據的流動訪問方面的安全建設意識也正逐步萌芽和發展;而 API 作為連接數據與應用的主要通道,成為了數據傳輸中最薄弱的環節之一。傳統的安全防護手段主要以邊界安全為主,在API 安全發展白皮書(2023)15 安全能力無法覆蓋到 API 敏感數
35、據的保護,從而導致 API 數據泄露和違規訪問的風險依然無法規避。由于 API 防護的缺失,企業對外暴露的 API、開放的 API、API通信中的敏感數據等問題均未得到應有的重視。攻擊者可以利用 API的認證授權、數據過度暴露、數據可遍歷、配置或設計錯誤等漏洞發起攻擊進行數據竊取。企業有效的落實 API 的安全治理,已經成為其滿足監管合規要求的必要舉措。5.企業跨部門協同存難題,企業跨部門協同存難題,API 安全全生命周期治理難安全全生命周期治理難實現實現 API 安全的治理需要從 API 生命周期的角度考慮,即從 API 的規劃、開發、測試、部署、運行和下線等各個階段全面考慮安全性,避免安全
36、漏洞被潛在的攻擊者利用。而實現全生命周期的安全治理需要跨多個部門,包括開發、測試、安全、運維等部門,達成共識并建立協作機制,共同保障 API 的安全。當前企業在 API 安全治理的跨部門合作中可能存在五方面問題。第一是缺乏有效的溝通渠道和協作機制。不同部門之間缺乏有效的溝通和協作機制,導致信息共享不暢,合作難度大。第二是職責劃分不清。不同部門對 API 安全治理的職責劃分不清,導致工作重疊或空缺,影響協作效率。第三是缺乏協同工具和流程支持。缺乏協同工具和流程支持,導致協作效率低下,難以有效跨部門合作。第四是優先級和利益沖突。不同部門的工作重心和利益有所不同,導致協作中可能存在優先級和利益的沖突
37、。第五是技API 安全發展白皮書(2023)16 術難度大。API 安全涉及到技術和業務的復雜性,不同部門可能缺乏相應的技術和經驗,導致難以合作和共同解決問題。三、API 安全防護體系建設思路 (一)(一)總述總述 建立 API 安全防護體系是確保企業信息安全的必要舉措,也是企業可持續發展的重要保障,該體系的構建過程是長期且持續的,且涉及多部門參與。安全部門作為 API 安全的第一責任人,可以優先基于API 生命周期構建安全防護模型,再結合自身業務情況,進一步基于IPDRR 模型實現 API 安全管理的閉環。注:IPDRR 模型是一種安全管理框架,其核心思想是通過識別、防護、檢測、響應和修復五
38、個步驟來全面評估和管理組織的信息系統、網絡和應用程序的安全。通過實施 IPDRR 模型,組織可以制定綜合的安全策略,包括技術、運營、人員、法律和合規等方面,以保護組織的信息和資產免受安全威脅的侵害。(二)(二)基于基于 API 生命周期構建安全防護模型生命周期構建安全防護模型 對企業而言,想要做好安全管理,全生命周期的 API 管理很有必要。首先,API 是企業的私有化資產,從設計和開發就是在企業內部完成,API 問題的產生通常也是由企業自身產生。所以,企業在管理角度上,有必要從開發和設計環節就開始考慮整個 API 的管理。其次,API 在整個業務生命周期當中變化非???,API 實現邏輯一旦發
39、生變化,很容易引入新的風險。因此,從 API 全生命周期來考API 安全發展白皮書(2023)17 慮 API 安全,圍繞規劃、開發、測試、部署、運行到下線的每一個環節加強安全建設顯得尤為重要。圖 1 API 生命周期安全管理模型 1.規劃階段:引入威脅建模理論規劃階段:引入威脅建模理論 在 API 全生命周期中,規劃階段至關重要,它決定了整個 API 開發過程的方向和目標。在規劃階段,企業應根據自身業務需求對風險進行評估,并制定 API 安全規劃和策略,以確保 API 的安全性和可擴展性。威脅建模作為一種系統方法,是安全規劃中的重要部分,它幫助企業評估 API 存在的威脅和漏洞,并采取相應措
40、施保護 API 的安全。API 安全發展白皮書(2023)18 在規劃階段,威脅建??蓭椭髽I評估 API 的安全風險,為后續的保護措施提供指導。企業可采用 ASTRIDE 和攻擊樹等模型進行威脅建模,分析攻擊者的目標、手段和途徑,并根據分析結果制定相應的威脅建模。同時,結合自身業務特點和歷史安全事件總結,制定安全策略和措施,為后續的開發、測試、部署和運行提供指導,確保 API 在全生命周期中的安全性。ASTRIDE 安全分析模型(Asset,Threat,Vulnerability,Risk,Impact,Detection,and Response)是一種綜合了攻擊樹和組合方法的安全風險評
41、估模型,它通過對系統進行建模和分析,可以識別出系統中存在的安全漏洞和潛在攻擊路徑,并且可以對這些漏洞和攻擊路徑進行量化的評估和排序。當企業在規劃階段引入威脅建模理論時,安全工程師應參與其中以確保 API 的安全防護能力:安全工程師可以在設計階段對 API 進行威脅建模,識別 API 的安全威脅和漏洞,并提出改進方案;安全工程師還可以提供安全規范和最佳實踐,以確保 API 的安全性和可用性,資源允許的情況下在設計階段對每個 API 進行威脅建模,線上的API 風險將會大大減少;資源有限的情況下,安全工程師可建設自動化威脅建模的能力,采用“重點業務人工評審”和“非重點業務自動化威脅建?!毕嘟Y合的方
42、式,對核心高風險 API(如賬號登錄、文件上傳、營銷活動等關聯 API)進行覆蓋。API 安全發展白皮書(2023)19 此外,安全工程師還可以在規劃階段為 API 安全設計提供指導和建議,包括讓開發人員遵循安全編碼標準和最佳實踐,加強代碼審計和安全測試,以及設計強有力的認證和授權機制等,同時協助企業評估 API 的安全性,提出適當的安全措施和流程,最大程度降低風險,加強企業數據資產保護。下表中的安全檢查表和最佳實踐可以作為威脅建模階段的參考:表 1 API 安全檢查表及最佳實踐 序號序號 名稱名稱 來源來源 1 OWASP REST 安全檢查表 https:/cheatsheetseries
43、.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html 2 API 安全工具和資源(APIsec)https:/ 3 API 安全檢查表 https:/ 4 JWT 安全檢查表 https:/ 2.開發階段:加強安全開發建設,引入安全工具開發階段:加強安全開發建設,引入安全工具 在開發階段,企業需要引入一系列安全措施來加強 API 的安全性。首先,可以制定安全開發規范,明確 API 開發的安全要求和規范,確保開發人員在設計和編寫 API 時充分考慮安全因素,從而減少潛在漏洞的存在。其次,企業需要開展安全開發培訓,將安全意識滲透到開發人員API
44、 安全發展白皮書(2023)20 的日常工作中。培訓應該包括最新的安全技術和最佳實踐,同時也應該提供實踐指導,幫助開發人員了解如何構建安全的 API,如何使用安全開發工具和技術來發現和修復漏洞。為了加強安全開發意識,安全團隊和開發團隊可以共同建立安全社區,定期舉辦安全相關的活動,分享最新的安全知識和案例,讓團隊成員共同學習、成長和分享。此外,企業可以使用安全開發工具來提高 API 的安全性。這些工具可以幫助開發人員發現并修復 API 中的安全漏洞,例如靜態代碼分析工具、API 安全驗證工具等。這些工具還可以自動檢測代碼中的漏洞和潛在安全風險,并及時提醒開發人員進行修復。通過上述安全措施的引入和
45、實施,可以在 API 開發階段有效提升企業的 API 安全防護能力,減少潛在安全風險和漏洞。如下列表中的安全編碼和開發規范,可供借鑒及參考:序號序號 名稱名稱 來源來源 1 OWASP 安全編碼實踐 https:/owasp.org/www-project-secure-coding-practices-quick-reference-guide/2 騰訊代碼安全指南 https:/ 3 威脅獵人 API 安全開發規范 https:/ 2 API 安全編碼和開發規范 API 安全發展白皮書(2023)21 在開發階段可以考慮使用如下工具加強安全建設:2.1 引入靜態代碼分析工具。嵌入到 CI/
46、CD 或者研發流程中,對代碼進行靜態掃描,識別潛在的代碼缺陷和安全漏洞。2.2 引入 API 管理工具。對 API 的文檔進行集中統一管理,監測API 的變更迭代的過程數據,幫助團隊實現 API 的快速迭代和管理。2.3 引入 API 安全驗證工具。驗證 API 安全實現的正確性,以保障驗證工作盡可能做到全面,相關工具如 FuzzDB、個人數據隱私監測類工具。3.測試階段:使用測試階段:使用 AST 類工具進行自動化漏洞測試,類工具進行自動化漏洞測試,提高覆蓋率提高覆蓋率 在測試階段,企業需要在實現 API 業務邏輯、API 穩定性、API性能測試的基礎上增加 API 安全的自動化測試。進行
47、API 安全自動化測試的目的是為了自動化掃描每一個 API,從“請求輸入”與“應答響應”兩部分去分析 API 是否存在漏洞。API 安全測試的常規內容主要包含 API 身份驗證、授權、輸入驗證、異常處理、數據保護、安全傳輸以及 HTTP Header 安全性等。API 數量多且在不斷地迭代更新,因此需要借助自動化工具來輔助進行安全測試,以便在測試階段提前發現 API 在研發過程中存在的安全漏洞。常用的工具有以下三類:SAST、DAST、IAST 工具,可以在測試階段提前發現存在的 API 安全漏洞。靜態安全檢測(Static Application Security Testing,SAST)
48、,其特API 安全發展白皮書(2023)22 點是分析應用程序的源代碼或二進制文件,通過語法、結構、過程、接口等來發現應用程序的代碼是否存在漏洞。動態安全檢測(Dynamic Application Security Testing,DAST),其特點是在應用程序的動態運行狀態下,模擬黑客攻擊行為,分析應用程序的響應,而確定應用程序是否存在漏洞。交互式安全檢測(Interactive Application Security Testing,IAST),相當于是 DAST 和 SAST 結合的一種安全檢測技術,通常會在應用程序中添加探針或 Agent 代理,收集應用程序、Web 容器、JVM
49、中的執行日志和函數調用信息,結合請求輸入與響應消息,分析應用程序中是否存在漏洞。4.部署部署階段:確保階段:確保 API 的部署和配置的安全性的部署和配置的安全性 在 API 部署階段,企業需要采取一系列措施來保證 API 的安全性。首先,在 API 部署前,企業需要對服務器進行安全掃描及加固,包括對服務器系統、應用、中間件等進行安全配置,開啟防火墻等安全措施,減少攻擊面,降低服務器受攻擊的風險。其次,企業需要確保數據在傳輸過程中的安全性,可以通過使用SSL/TLS 等加密協議來加密數據傳輸,防止數據在傳輸過程中被竊取或篡改。此外,企業需要根據業務需求限制對 API 的訪問,確保只有授權的用戶
50、或系統能夠訪問 API??梢酝ㄟ^ IP 白名單、Token 鑒權等方式API 安全發展白皮書(2023)23 進行訪問控制,避免未授權的用戶或系統訪問 API。最后,企業可以使用安全配置檢測工具來檢測 API 部署和配置的安全性,包括服務器的操作系統、中間件、數據庫等的配置,防止因配置錯誤或漏洞而導致的安全風險。在部署階段可以考慮使用如下工具加強安全建設:4.1 漏洞掃描工具。通過模擬攻擊,幫助企業自動發現 API 部署時存在的常見漏洞和安全配置問題,并提供修復建議。4.2 安全配置管理工具??梢詭椭髽I管理 API 的安全配置,監控配置的變更,及時發現不安全的配置并采取措施進行修復。5.運維
51、階段:利用工具及時運維階段:利用工具及時感知感知 API 攻擊威脅攻擊威脅 在運維階段,企業可以利用各種安全工具來及時感知 API 的攻擊威脅,實現 API 的分層防護,確保 API 的安全性。這些工具包括 DDoS防火墻、Web 應用程序防火墻(WAF)、API 網關、API 安全審計工具等。5.1 DDoS 防火墻。針對分布式拒絕服務攻擊(DDoS)的安全工具,DDoS 防火墻可以通過各種技術手段,包括 IP 黑名單、限制流量等,識別和過濾 DDoS 流量,保護 API 免受 DDoS 攻擊。5.2 Web 應用程序防火墻(WAF)。通過分析來自客戶端的 HTTP請求,并根據其規則庫對其進
52、行檢查,以檢測和阻止惡意攻擊。在 API防護過程中,WAF 通常用于阻止 SQL 注入、跨站腳本攻擊(XSS)等攻擊請求,以及常規的 BOT 攻擊等。WAF 可以提供實時監測和分API 安全發展白皮書(2023)24 析 API 的訪問日志,并能夠迅速發現異常行為。WAF 可以記錄所有請求數據,包括來源 IP、用戶代理、參數等,并能夠根據事先設置的安全策略進行分析和識別。當異常行為被發現時,WAF 可以立即采取行動,根據預設的安全策略阻止惡意請求,從而快速響應和快速阻止攻擊。此外,WAF 也提供了一些高級功能,如基于 AI 的安全分析、虛擬補丁等,可以根據攻擊行為自動調整安全策略。在運維人員發
53、現新的攻擊行為后,可以在 WAF 上進行配置和調整,以提高 API 的安全性。WAF 在實際使用中也存在著一些片面性。例如,WAF 不能解決所有的安全問題,大部分利用 API 邏輯漏洞進行攻擊的行為可以繞過WAF 的防御。另外,如果 WAF 的規則庫更新不及時或者設置不當,就會導致誤報或漏報,從而影響 API 的正常使用。因此,企業在使用WAF 時需要進行定期維護和更新,以保證其有效性和準確性。5.3 API 網關。能夠實現認證、授權、訪問控制和數據脫敏,從而提高 API 的安全性。API 網關具有身份認證、訪問控制、數據校驗、限流熔斷等功能,可以幫助安全團隊管理 API。但是,對于內部開發人
54、員來說,使用 API 網關需要打通持續集成(CI/CD)與 API 網關的接口,準備好 API 導入數據供 CI/CD 調用,這會增加開發人員的工作量,并影響發布進度。此外,當所有后端服務的流量都必須通過 API網關進行通信時,會對原有通信性能和 API 的穩定性產生影響,這是推進 API 網關工作的負責人員需要面對的最大挑戰。因此,是否需要API 安全發展白皮書(2023)25 使用 API 網關需要根據業務的實際情況進行評估。5.4 API 安全審計工具。能夠通過流量或者 WEB 日志的持續分析,動態識別企業的 API 資產、API 資產關聯的敏感數據、賬號信息,具備對于各類資產進行自動分
55、級分類的能力,支持通過 API 資產的流量差異比對發現僵尸 API、影子 API,老版本、功能重復的 API 資產。該工具通過對 API 資產的流量上下文及敏感數據的持續分析,可以實時發現 API 資產的授權類、認證類、數據暴露類、配置及設計不合理等各類邏輯漏洞,通過外部情報和機器學習模型來感知針對 API 的低頻慢速的攻擊風險,使用賬號、IP、訪問時間、訪問 API、訪問敏感數據等多重維度建設的 UEBA 模型來感知賬號共用、借用、盜用等行為導致數據泄露的攻擊風險。6.下線階段:及時下線僵尸影子下線階段:及時下線僵尸影子 API 在 API 下線階段,企業需要進行特定的安全下線處理措施來保障
56、系統安全,數據清除和安全審計是兩個關鍵的方面。數據清除是指將與 API 相關的數據和配置清除干凈,以防止敏感信息被未經授權的人員獲取。安全審計則是指對 API 下線過程中對 API 資產進行審計和維護,以及查看是否存在安全風險,以便在今后的安全事件處理中作為重要依據。API 資產審計工具支持企業動態 API 資產的維護,識別哪些 API 是應該下線的,如僵尸 API,老版本 API、功能重復的 API,通過審計工具的安全事件對已經完成下線操作的 API 資產進行二次確認,對于使用頻率較低的 API(如營銷活動 API、招聘 API 等)也API 安全發展白皮書(2023)26 可以進行有效的資
57、產分類及業務監控。(三)(三)API 安全閉環管理要求和建議安全閉環管理要求和建議 在日益嚴峻的網絡安全環境下,API 安全建設絕非易事。API 全生命周期管理涉及企業各部門角色的參與,投入工作量極大,企業應該根據實際情況來調整投入產出比。而從高效防御的角度出發,企業可以從 API 的上線運行階段入手,基于 IPDRR 安全模型實現 API 安全閉環管理,結合自身的業務情況有序開展 API 安全實踐?;?IPDRR 模型,企業可通過持續識別 API 資產潛在威脅和漏洞、提供安全保護措施、實施實時監測和事件檢測、迅速響應安全事件、以及實施恢復策略和業務持續性計劃,全面保護 API 的安全性和可
58、靠性,最大化降低甚至避免 API 風險。圖 2 API 安全閉環管理 API 安全發展白皮書(2023)27 1.Identify:構建可持續的識別能力:構建可持續的識別能力 1.1 API 資產動態識別 API 資產動態識別能力是 API 提供者和攻擊者之間的競賽,要在攻擊者之前發現 API,提前感知和了解到系統可能的攻擊面。因為 API是不斷在研發迭代的,所以持續動態梳理 API 的能力顯得至關重要。企業可以從 API 安全網關、負載平衡或交換機鏡像的網絡流量中對API 資產進行動態識別。API 資產的動態識別需要遵循全面性原則。首先,API 資產的動態識別需要覆蓋企業的全部應用系統類型,
59、包含終端用戶系統、內部應用系統、合作方系統、第三方組件管理系統等范圍;其次,API 資產的動態識別需要全面支持各類應用協議,如 REST、RPC、GraphQL等。API 資產的動態識別需要遵循準確性原則。API 資產的動態識別過程中首先需要具備有效去除掃描流量等非正常請求的干擾的能力,避免非正常流量導致無效 API 資產數量無限擴大,此外需要具備針對存在參數變量類似、路徑高度重合的 API 資產合理規約的能力,避免未合理規約導致同屬性 API 資產數量無限擴大,最后需要具備針對接口類型參數化的 API 資產合理拆分的能力,避免未合理拆分導致 API資產安全特征模糊。API 資產的數量無限擴大
60、或者未合理拆分,都會導致 API 安全運營的無效工作增大,最終使得 API 安全運營工作難以開展。API 安全發展白皮書(2023)28 1.2 敏感數據動態檢測 API 資產作為企業流動數據的載體,企業應對流動數據進行數據分級分類治理,對 API 承載的敏感數據進行持續監測評估,動態識別API 接口中的敏感數據類型并自動生成 API 接口與敏感數據類型的映射關系。敏感數據動態識別能力應支持自定義的敏感數據類型識別規則,并支持自定義敏感數據類型的分級分類。1.3 賬號資產自動提取 賬號資產自動發現能力是企業數據流動風險發現的基礎。API 資產的交互過程中承載了賬號及其鑒權信息,企業可以通過從
61、API 交互過程中自動提取出賬號以及賬號的訪問日志信息,從而可以清晰掌握“誰通過什么 API 訪問了什么敏感數據”。企業基于上述訪問日志信息可以對賬號異常行為進行有效的治理及溯源。1.4 API 資產自動化管理 API 資產自動化管理能力是 API 資產安全運營的基礎。企業可從API 資產的網絡屬性、應用屬性、關聯敏感數據類型、業務場景屬性以及使用組件屬性等維度對資產進行自動化分級分類。企業可以根據API 資產的分級分類結果確定安全運營工作的優先級,有效提升 API安全運營工作的效率。1.5 漏洞自動發現 企業需要建設具備持續監測 API 存在的授權、認證、數據過度暴API 安全發展白皮書(2
62、023)29 露、配置、邏輯設計錯誤等漏洞的自動化識別能力。漏洞的自動化識別能力需要遵循全面性原則,不僅需要對自身業務存在的漏洞進行覆蓋,也需要覆蓋對第三方開源組件及中間件進行覆蓋。漏洞的自動化識別能力需要遵循準確性原則,在漏洞識別的過程中需要去除掃描流量的干擾,可以有效降低掃描流量導致的漏洞誤判,從而極大降低安全人員對漏洞事件審計工作的工作量。2.Protect:構建實時的防護能力:構建實時的防護能力 2.1 認證授權 建設有效的認證授權是 API 安全的關鍵,是保護 API 系統安全的第一道防線。企業應建設統一的認證授權體系,確保只有通過認證的用戶或者應用程序才能訪問被授權的 API 接口
63、。企業可以基于OAuth2.0 或 Open ID Connect 等協議完成認證授權體系的建設。2.2 訪問控制 企業應采取訪問控制措施,限制 API 接口的訪問權限,以確保API 系統僅被授權用戶或者應用程序所訪問,并提供完整的訪問控制日志用于審計。訪問控制的具體實施措施可以包括基于角色的訪問控制、基于屬性的訪問控制、多因素身份認證等方式。企業可以根據實際需求選擇合適的訪問控制策略。2.3 限流限速 企業應針對 API 接口的訪問采取限制措施,限制 API 接口的訪API 安全發展白皮書(2023)30 問頻率、訪問次數等,以避免 API 接口被惡意攻擊者利用導致資源無效消耗。API 接口
64、的限制措施的具體實施可以包括 IP 地址限制、請求次數限制、黑白名單限制等。2.4 信息傳輸保護 企業應保障 API 在信息傳輸過程中的機密性和完整性。信息傳輸保護可以通過采用 TLS/SSL 協議、HTTPS 等方式來實現。TLS/SSL協議是一種安全傳輸協議,可以保證通信過程中的數據傳輸安全。2.5 數據加密 企業應對敏感信息的交互進行加密和脫敏處理,特殊的敏感信息需要被加密或做脫敏處理,例如身份證號、銀行卡號、手機號等,以減少敏感信息的泄漏風險。3.Detect:構建全面的檢測能力:構建全面的檢測能力 3.1 API 邏輯攻擊檢測 當攻擊者利用 API 的邏輯漏洞發起數據爬取、惡意注冊、
65、掃號、爆破、短信轟炸、營銷欺詐的惡意攻擊時,為了突破現有安全設備(如WAF、API 網關)的檢測策略,一般選擇接入代理 IP SaaS 服務商來實現低頻訪問,接入虛擬手機卡 SaaS 服務商來突破賬號身份限制。當攻擊者針對 API 發起低頻無特征攻擊時,原有安全設備的風險檢測模型就會失效,因此,企業在基于流量特征及行為特征構建針對 API邏輯漏洞的攻擊檢測模型時,應當引入攻擊資源情報作為檢測模型的判定依據,從而準確識別出針對 API 的邏輯攻擊風險,有效降低攻擊API 安全發展白皮書(2023)31 檢測的誤判率,提升 API 安全運營的工作效率。圖 3 某互聯網企業業務請求量 圖 3 中第一
66、條曲線是總業務流量趨勢,非常規律;第二條曲線是某個關鍵 API 的訪問量,波動正常,如果基于規則引擎識別,容易產生誤判;第三條曲線是該 API 下風險 IP 請求量占比,在 API 訪問量低的情況下,仍然能夠精準發現攻擊風險。3.2 賬號違規操作檢測 攻擊者可以利用內鬼來盜取敏感數據,也可以借助撞庫、賬號暴力破解、社工釣魚等方式獲得敏感的賬號,進而利用授權賬號進行違規的操作,如違規獲取大量敏感數據。賬號違規操作行為的檢測,需圍繞賬號的歷史行為以及賬號和同組織的人在登錄環境、登錄 IP、獲取數據的時間、訪問站點和數據的情況等行為方面構建基線,基于UEBA(User and Entity Beha
67、vior Analytics 用戶實體行為分析)的模型來監測賬號違規操作的行為。API 安全發展白皮書(2023)32 3.3 IP 異常行為檢測 攻擊者的攻擊都需要通過 IP 資源來完成,針對 IP 構建歷史行為畫像如數據訪問、地理位置、API 訪問序列、風險情報畫像等,基于機器學習的方法檢測 IP 的異常行為,如路徑掃描、漏洞掃描、單一API 請求過多、境外 IP 獲取敏感數據等異常行為?;?IP 風險情報來構建的檢測模型,準確率高,可解釋性強。4.Respond:構建高效的響應能力:構建高效的響應能力 4.1 攻擊威脅分析與響應 企業應建設安全大數據分析平臺、安全信息與事件管理系統(S
68、IEM)等,制定相應的應急預案和流程,幫助企業對所有 API 安全事件進行統一監測,并在發生威脅事件時快速感知和響應。通過實時監測和數據分析,企業可以更快地發現潛在安全問題,及時進行預警和處置。同時,企業還可以在日常運營中積累足夠的數據和經驗,進一步提高 API 的安全性和可靠性。4.2 攻擊威脅預警和溯源 企業需要借助風險情報和大數據分析技術,對 API 的訪問日志進行分析,挖掘攻擊流量,并對攻擊流量進行解釋和溯源,做到及時預防和響應??蓮臉I務流量中細化攻擊行為,結合攻擊者歷史情報信息對攻擊者的資源、手法、意圖、團伙情況、潛在目標進行關聯跟蹤分析,進而構建攻擊者情報庫,對攻擊者進行持續跟蹤。
69、4.3 數據泄漏預警和溯源 API 安全發展白皮書(2023)33 企業應對存在數據信息販賣的情況進行有效監測?;诎稻W等數據源的監測數據,進行臟數據過濾、二手信息過濾,結合數據售賣者的置信度對交易數據準確性和及時性進行分析,提煉出準確的數據泄漏預警信息,及時預警數據泄漏事件。同時,利用大數據日志平臺,對泄漏的數據進行追蹤溯源,找到泄漏源頭,針對性進行修復,避免大規模的數據泄漏事件發生。5.Recover:構建閉環式的修復能力:構建閉環式的修復能力 5.1 漏洞修復管理 企業應構建漏洞修復管理機制,統一收集 SRC、滲透測試、基于旁路流量的 API 安全工具持續挖掘安全事件中暴露的漏洞,做好漏
70、洞的修復過程管理,以避免已知漏洞被攻擊者利用。企業可以通過修復漏洞的方式提高 API 接口的安全性和可靠性。5.2 安全政策和規范更新 針對安全事件中暴露出來的安全問題,及時更新安全政策和規范,以確保員工遵守最新的安全要求。同時,企業還可以針對安全事件的經驗和教訓,進行相應的安全策略和規范的調整和改進。5.3 加強員工安全教育 通過培訓和教育,提高員工的安全意識和技能,讓員工能夠更好地理解安全政策和規范,并在日常工作中遵守相應的安全要求。這樣可以有效減少因員工失誤而導致的安全事件。5.4 安全事件總結和分析 API 安全發展白皮書(2023)34 對檢測到的安全事件進行總結和分析,評估安全事件
71、對企業的影響和損失,及時調整和改進安全策略和措施,以避免類似事件的再次發生。通過總結和分析,企業可以不斷完善 API 接口的安全性和可靠性,提高企業的整體安全水平。四、API 安全未來發展趨勢展望 在數字化浪潮下,企業加速轉型步伐,API 漏洞所造成的安全挑戰不斷擴大,攻擊手段頻現且難以防范,API 攻擊事件以及防護也受到了業內的廣泛關注。新形勢下,對于 API 安全攻防的發展趨勢及未來展望如下。建立基于不同行業需求的 API 安全體系標準。在引導和鼓勵企業、安全廠商深化數字化業務的同時,還應鼓勵安全廠商加快針對API 安全新技術新方法的研究與實踐,推動 API 安全的體系化發展。針對不同細分
72、行業,積極開展符合行業發展規律的 API 安全防護標準制定,推動引導 API 防護技術發展。2022 年,中國信息通信研究院聯合多家企業撰寫了應用程序接口全生命周期安全管理成熟度要求,從 API 開發、測試、發布、運維、迭代、下線等各個階段規范API 安全能力,對助力企業不斷優化升級安全技術,落地 API 全生命周期安全防護體系具有重要意義。企業可參照該標準對自身 API 安全防護體系進行設計、管理和評價。提高人員安全意識。企業安全管理及運維人員應充分認識到 API安全的重要性以及泄露的危害性。增強人員安全意識可以大幅降低安API 安全發展白皮書(2023)35 全風險。企業可通過定期培訓等方
73、式對從業人員進行安全意識、安全素養的訓練。強化發展 API 融合防護技術和解決方案。強化發展融合動態防護、機器學習、情報分析、行為分析、特征識別等技術的新型 API 安全防護解決方案,以解決 API 面臨的新型威脅,引導和鼓勵企業、安全廠商在深化數字化業務的同時,加快針對 API 安全新技術新方法的研究與實踐,從而推動 API 安全的體系化發展。API 安全發展白皮書(2023)36 附錄 1 2022 年全球 API 攻擊重要事件(一)(一)某大型社交平臺某大型社交平臺 API 安全漏洞暴露超安全漏洞暴露超 500 萬用萬用戶數據戶數據 2022 年,某大型社交平臺報告了從 2021 年底到
74、 2022 年發生的API 泄露事件,暴露了超 500 萬用戶賬戶的個人信息數據(實際賬戶數量可能要高得多)。該 API 漏洞允許任何一方在沒有任何認證的情況下,通過提交電話號碼或電子郵件,獲得任何用戶的 ID,使得攻擊者可以利用該漏洞進行大規?!皰咛枴惫?。雖然該平臺修復了這個漏洞,但仍然暴露了數百萬用戶的私人電話號碼和電子郵件,部分數據在暗網上出售,甚至是被免費發布的。網絡犯罪分子可能會利用從這次泄露中收集的信息,針對用戶進行電子郵件網絡釣魚、語音網絡釣魚和詐騙,試圖欺騙用戶交出個人信息和登錄憑據。(二)(二)某大型電信公司某大型電信公司 API 漏洞導致巨大經濟損失漏洞導致巨大經濟損失
75、2022 年,某大型電信公司報告稱有 1000 萬個賬戶被攻破,攻擊者隨后勒索了 100 萬美元,并聲稱擁有超過 1100 萬條用戶記錄。這名黑客威脅說,如果該公司在一周內不付款,他就將這些數據打包出售。未驗證 API 是此次事件的罪魁禍首,用于測試的 API 被暴露在互聯網上,并且缺少身份驗證檢查,也就是說互聯網上的任何人都可以向此 API 發出數據請求,而無需提供任何憑據或令牌來證明其身API 安全發展白皮書(2023)37 份。還有另一個問題是攻擊者通過簡單地更改 ID 號便能輕松請求數百萬條記錄。根據 2023 OWASP API 安全十大漏洞,用戶身份驗證漏洞是第二大 API 漏洞。
76、(三)(三)某跨國運營商的某跨國運營商的 API 數據泄露導致超數據泄露導致超 3000 萬萬客戶賬戶受損客戶賬戶受損 某跨國運營商 2022 年 12 月透露發現了一起數據泄露事件,并且影響了超 3000 萬個付費和預付費賬戶,預計將因此損失大量資金。攻擊者通過暴露的未經授權的 API 竊取了超 3000 萬個付費和預付費客戶帳戶的個人信息。受影響的 API 泄漏了客戶帳戶數據,包括客戶姓名、賬單地址、電子郵箱、電話號碼、出生日期、該平臺賬戶號和賬戶訂閱條目數與套餐功能等信息 該跨國運營商已通知美國相應的聯邦當局,并正在與他們合作調查此次違規事件。在此次黑客攻擊事件中被泄露敏感信息的客戶現在
77、已收到運營商的通知。(四)(四)API 安全漏洞影響多家汽車制造商安全漏洞影響多家汽車制造商 2022 年安全研究人員發現,黑客可以利用新的 API 安全漏洞遠程控制、跟蹤和轉移車輛,此外他們還可能危及數百萬汽車制造商和經銷商的帳戶,獲得對內部系統的管理訪問權限,并訪問客戶和員工信息,泄露來自十多家知名汽車制造商的個人信息。其中某國際知名豪車品牌在 CMS 中存在 SSO(單點登錄)漏洞,暴露了后端 API,攻擊者將有機會從 Java script 中提取憑據,這意味API 安全發展白皮書(2023)38 著允許攻擊者創建、修改、刪除任意的該汽車品牌客戶賬戶,甚至可以將自己設定為車主從而接管任
78、何該車企個人賬戶。API 安全發展白皮書(2023)39 附錄 2 API 安全最佳實踐 (一)(一)金融行業金融行業 1.背景與挑戰背景與挑戰 某證券公司在數字化轉型期間,內部建設的數字化應用系統的安全設計不夠細致,容易遭受撞庫、掃號等攻擊,導致賬戶信息泄露。另外,攻擊者利用未授權,敏感數據未脫敏等缺陷,爬取大量的用戶資料,交易信息等數據,造成嚴重的數據泄露。企業需要全面梳理和掌控 API 資產,了解敏感數據的流動情況,及時發現和修復缺陷、漏洞,防止系統被攻擊,同時確保符合數據安全合規要求。2.實踐實踐 通過借助 API 安全管控平臺的能力,該證券公司構建了 API 安全審計體系,一方面通過
79、接入的流量識別線上 API 存在的缺陷并及時聯動業務進行閉環修復,尤其是外部開發團隊的系統,未授權類缺陷過多,這類缺陷很容易被攻擊者利用,造成嚴重的數據泄露。期間共檢測出 20 類缺陷,累計協助修復 300 余個 API 缺陷。其中涉及有接口存在未授權訪問,關鍵涉敏數據未脫敏漏洞,該接口可以不經授權,直接通過用戶 ID 獲取到用戶的保單信息,其中包括了姓名、生日、手機號、賬號、銀行卡號、家庭地址等大量未脫敏的敏感信息。另一方面也結合了平臺內置的威脅情報特征庫與異常行為模型,發現外部的惡意攻擊并及時部署 API 風控策略、處置惡意請求。共監測到風險事件 23 起,涉及大量敏感信息爬取、撞庫攻擊等
80、風險,存API 安全發展白皮書(2023)40 在嚴重的數據泄漏風險。比如攻擊者利用多個惡意 IP 代理平臺爬取了大量客戶的賬號信息,包括姓名、手機號、風險投資等級等。同時發現攻擊者利用某數據中心 IP 發起了超 8 萬次撞庫攻擊,嘗試獲取賬戶登錄信息。同時平臺也將該部分攻擊情報同步到 WAF 設備進行阻斷,避免了數據泄露事態進一步擴大導致的用戶權益受損與監管責罰風險。(二)(二)互聯網行業互聯網行業 1.背景與挑戰背景與挑戰 某互聯網公司是內容社區領域中的 top 企業,在激烈的競爭環境中通過敏捷開發保持較高的產品更新頻率以獲得更多的市場,但也導致存在大量老舊業務 API 未做下線處理,長期
81、處在安全人員的的視野范圍之外,安全策略和監控措施跟不上。此外,黑產攻擊時會利用大量的、低成本的動態代理 IP 偽裝成正常的請求流量,繞過傳統 WAF和 API 網關的策略對敏感數據進行低頻、慢速地爬取,企業往往很難發覺。2.實踐實踐 通過部署 API 安全管控平臺,該互聯公司建設了 API 資產管理與風險發現于一體的治理流程?;谄脚_ API 自動化規約的圖模型技術,梳理 APP、小程序、網頁中面向用戶、內部員工、合作伙伴及第三方供應商等開放場景中的 API,建立完整可視化的 API 資產清單,共梳理 API 資產一萬五千余個,其中涉敏 API 超四千個,包含了大API 安全發展白皮書(202
82、3)41 量多版本 API 與僵尸 API。同時基于平臺內置的威脅情報特征庫與異常行為模型,發現針對企業業務的攻擊風險,共識別 API 風險 4 類 81 個事件,包含利用秒撥代理 IP 進行數據爬取、撞庫攻擊和營銷欺詐等。其中涉及攻擊者利用 4.9 萬個代理秒撥對其中 2 個站點,超 10 個服務接口發起 90 萬次爬蟲攻擊,主要集中在 PC 端站點,爬取用戶、內容、關注好友等頁面的信息,從而針對風險及時采取限制措施,避免進一步數據泄露。另一起事件是平臺發現移動端營銷活動的簽到接口遭遇批量攻擊,攻擊者使用虛假手機號與代理 IP 對簽到接口發起超 7 萬次請求,通過簽到手段獲取商家的活動積分以
83、兌換現金或商品福利。API 安全管控平臺及時對攻擊事件進行告警,進一步關聯出惡意用戶,并及時聯系業務運營方取消了未被兌換的營銷獎勵,挽回了 80%的損失。(三)(三)傳統數字化傳統數字化 某連鎖酒店集團公司,近些年為支撐遷移至線上的業務快速發展,企業采購或自研大量內部運營系統,這部分系統往往缺乏較嚴格的訪問權限管控與日志留存,甚至不同的內部系統有不同的賬戶體系,分散式的賬戶權限管理需要花費較大的成本且容易出現遺漏。因此很難有人能夠明確企業內有多少內部系統多少賬號,以及賬號通過 API 訪問了什么數據。同時產業化的黑產團伙上游在匿名平臺大肆高價收購數據,驅使內部員工違規竊取數據的事件頻發。通過部
84、署 API 安全管控平臺,該連鎖酒店集團公司基于 API 流API 安全發展白皮書(2023)42 量分析還原了“員工”和“數據”之間的雙向可視化追溯通道。不僅識別出內部系統資產、賬號資產,并且對賬號的安全狀態與行為進行安全審計。過程中共識別超過 200 個內部系統,共梳理訪問賬號資產 1600余個,可訪問涉敏的賬號約 1000 個,超 1500 個內部員工賬號、100個三方調用賬號。通過平臺發現在內部的運營系統存在未授權、越權等缺陷,內部人員盜取敏感數據的門檻極低,業務方做了及時修復。并且發現存在弱密碼帳號 200 余個,存在著被惡意爆破、盜號的風險,也及時讓相關業務通報糾正,并且宣貫密碼安全意識。同時發現多名內部員工賬號在非工作時間獲取涉敏數據過多,比如有1個采購部門的賬號12:00訪問客戶信息,獲取涉敏數據類型包括賬號、姓名、手機號、酒店信息,安全人員及時對該賬號進行凍結以及聯系業務做進一步處理。