隨著雲原生和軟體開源技術的蓬勃發展，越來越多的開發平臺和第三方服務快速湧現，應用系統與功能模組的複雜性不斷提升，應用開發深度依賴於應用程式介面（Application Programming Interface，API）之間的相互呼叫。近年來移動應用深入普及，促使社會生產、生活活動從線下轉移到了線上，API在其中起到了緊密連線各個元素的作用。為滿足各領域移動應用業務需要，API的絕對數量持續增長，透過API傳遞的資料量也飛速增長。開發框架的演進也是推動API發展的重要因素，隨著容器化、微服務的發展，API作為支撐的重要技術也逐步被大規模的使用。

API作為連線服務和傳輸資料的重要通道，已經從簡單的介面轉變為IT架構的重要組成部分， 成為數字時代的新型基礎設施，以及數字化時代一種重要且特殊的數字化資產，隨之而來的則是對於API安全問題的思考。本文結合API發展趨勢與面臨的安全風險，以IAST程式碼疫苗技術為抓手，深入討論IAST技術在API安全方面的應用。

一、 API安全基礎介紹

1.1 API發展

API是系統不同組成成分的銜接約定，在當下已成為應用間連線服務和傳輸資料的重要通道，成為數字時代的新型基礎設施。

API服務的發展歷程也可以看做從單體架構走向微服務架構不斷變化的過程。隨著網際網路技術的不斷髮展，其IT基礎設施架構日趨複雜，傳統的單體架構已經不適用於當下敏捷的要求。雲和容器這兩種技術的興起，為實現企業持續整合和快速部署專案的需求，微服務已成為高速增長公司中構建應用程式的首選。伴隨著企業數字化轉型，企業應用經歷了從內部服務呼叫到開放平臺的場景需求變化，API也經歷了從1.0單體架構到2.0 SOA架構再到3.0 REST架構的技術變革，實現透過API輸出的資源來完成產品和服務的迭代升級。

圖1 API發展歷程

 

1.2 API安全挑戰加劇

根據Akamai的一項統計，API請求已佔所有應用請求的83%，預計2024年API請求命中數將達到42萬億次，API承載了應用各元件間資料的流動，成為資料互動最重要的傳輸方式之一，也因此成為攻擊者竊取資料的重點攻擊物件，據統計有超過四分之一的組織在沒有任何安全策略的情況下執行著基於API的關鍵應用。根據Salt Security的報告，82%的組織對自己是否瞭解API資產毫無信心，同時還有22%的組織表示不知道如何發現哪些API存在安全風險，面對API安全威脅不斷複雜化、多樣化的趨勢，政府與企業等的數字化系統正在面臨來自多方面嚴峻的安全挑戰。

二、 API面臨的安全風險

2.1 API資產管理混亂

雲原生等新理念的廣泛應用加快了新型別API的開發，API數量呈指數增長。在高速迭代的場景下，企業幾乎每天都有新業務需要上線，但未必所有的新業務都經過全面審計，從而很難在第一時間發現和識別這些新的API。同時由於存量API的數量龐大，企業在API管理方面面臨許多問題，自身不清楚自身資產擁有多少API、API處於何種狀態以及API的更新迭代情況。如若自身API都未進行深層次的梳理清洗，何談API安全防護。

2.2 API應用安全風險

“缺陷是天生的，漏洞是必然的”，在系統研發和執行的過程中，API不可避免會產生安全漏洞。開發人員在研發過程中享受技術發展紅利的同時，常常忽視了安全的要求，使用的程式碼或不當的配置引入了安全風險，如OWASP曾在2019年提出針對API的10項常見危險清單，如下表所示，其中有常見的的加密、鑑權等協議問題，同時也包含Web入侵、中介軟體入侵及資料洩露風險。對比更為熟知的OWASP Top 10, 從API Top 10評級可以看出，傳統的Web通用型別漏洞不是API重點關注的風險，許可權和資源將是API的主要風險面，這也對API安全廠商提出了更高的要求。

 

2.3 API資料安全風險

因性質使然，API會暴露應用程式邏輯、個人身份資訊、業務資訊等敏感資料，也正因為如此，攻擊者逐漸將API當做攻擊的首選目標，利用非法控制和使用API介面直接竊取資料等隱蔽而嚴重的問題進行攻擊。

透過API可以直接與後端進行通訊，如果網路攻擊者能夠直接訪問API層，就相當於繞過了許多安全防護措施，可以直接訪問敏感資料，造成許多重大資料洩露事件。

2021年：Facebook洩露3.3億使用者資料，包括使用Facebook API的第三方應用程式的資料。

2021年：CD Projekt Red遊戲公司遭受勒索軟體攻擊，攻擊者竊取了原始碼並威脅洩露，該公司的API金鑰也被盜。

2020年：Twitter遭受大規模安全漏洞，攻擊者利用API獲取了多位名人和企業的賬戶，併發布了欺詐性資訊。

2019年：約8000萬Facebook使用者的個人資料被盜，攻擊者透過利用Facebook API的漏洞獲取了這些資訊。

企業龐大的資料足以勾勒出數以億計的使用者畫像，API作為連線服務和傳輸資料的重要通道，在雲原生等新場景下，API安全很大程度決定了資料安全。

三、 IAST在API安全 領域的關鍵應用

3.1 API資產發現及管理

3.1.1 API資產識別

傳統的API資產發現方式主要透過旁路映象或主機串聯的方式，透過流量分析持續性的捕獲傳輸過程中的API資源並進行自動識別，再結合人工梳理的方式二者形成現有應用的API資產。但傳統的方式由於技術原因存在覆蓋度不全、框架協議受限等問題，導致難以全面獲取API資產，存在未知的“殭屍”API、過期API、失效的API引數等。

IAST透過插樁的方式天然地適應於多微服務模式，可以在測試階段將Agent與應用實現融合執行，如何將IAST的工具優勢與API的發現能力融合則是技術關鍵。

IAST插樁技術可以從應用中提取相關API資產，自動地分析應用和API中的自有程式碼，梳理應用中的API資產。在微服務架構下，IAST能夠對於同一應用下的API資產進行合併，實時感知API介面訪問情況，發現隱藏或廢棄的API資產。

經過實際場景的不斷積澱，現階段IAST進行資產發現的方式主要有三種：

1、框架動態分析

透過插樁在應用執行時環境的探針，從介面實現程式碼、配置檔案等位置，精準識別介面清單、介面簽名、請求方法、請求引數等資訊。

原理則是依賴於應用中已有的標準方法，在程式執行時透過反射讀API定義，調取框架中特殊的介面定義方法，透過已有的框架方法獲取程式執行中的API資產。

例如大家常用的Spring框架，標準的Spring通常將介面寫在Controller層，透過分析Controller中的介面既可以獲取專案的全部介面。結合位元組碼插樁技術，獲取ApplicationContect初始化完成的原始碼位置，透過ApplicationContext物件的getBean方法獲取RequestMappingHandlerMapping類，最後透過getHandlerMethods（）方法獲取所有介面。探針獲取後將介面資訊封裝，傳送至Server端進行處理分析，獲取API資產的一手資料。

2、Agent獲取測試流量。

透過插樁在應用執行時環境的探針，持續對傳送到應用的流量進行監控和分析，進一步梳理應用介面資產清單。

3、特徵檔案提取

此種方式較第二種方式不依賴於已有的功能測試，在系統執行時標準的應用框架中會含有swagger、yapi等介面檔案，透過位元組碼轉換能力在應用執行時發現並解析介面檔案，從而全量獲取API資產。

IAST透過在應用的各個服務中部署探針，結合框架動態分析能力從應用中初步獲取API資產清單。在功能測試、效能測試等應用執行時環境中，探針持續對傳送到應用的流量進行監控和分析，進一步梳理應用API資產清單和進行行為分析，二者相互結合，實現在測試階段初步梳理應用已有的API資產及使用情況。

3.1.2 API資產管理

當前旁路映象或主機串聯等基於流量的API識別可以在測試流量中實時獲取應用中已有的API。但隨著系統迭代升級，流量方式在持續化獲取API的同時存在難以關聯應用版本的問題。

IAST透過上述方法獲取API列表後，根據獲取的API的引數名稱和型別、介面的函式簽名、請求響應、呼叫情況等基礎資訊後，根據內建或自定義的API資產分組策略對同類資產進行統一管控。

系統版本迭代升級過程中，IAST探針在執行過程中具有Version的版本概念，結合Jenkins和其他CI/CD流程或企業內部的版本定義，自動或手動將Version資訊記錄在探針引數中。結合IAST探針插樁技術，在應用迭代的過程中記錄不同版本的API資產資訊，對於同一應用下的API資產進行清洗合併，一方面補充傳統API識別方法對於版本概念的缺失，在此基礎上可透過版本比較等方式獲取最新應用版本的API變動情況，更加細緻地進行API資產管理；另一方面實時感知不同版本的API介面訪問變動情況，發現因版本更迭帶來的隱藏或廢棄的API資產，實現殭屍API、影子API的識別發現。

3.1.3 API資產拓撲圖

IAST透過探針技術直接檢測應用中各個API執行情況，在進行功能測試時，結合被動汙點分析技術，實現對於外部輸入的資料進行全鏈路追蹤，結合API資產獲取服務間API呼叫關係，形成API資產拓撲圖，從函式級分析API的關聯關係。

 

圖2 資產拓撲示例

3.2 API威脅檢測

針對API面臨的威脅，傳統的安全防禦並不能完全解決問題，事實證明事後救火併沒有真正解決API安全帶來的問題。為了解決應用API安全的挑戰，降低安全成本，在上線前對API進行全面的安全管控。

透過IAST互動式應用安全測試技術將API安全測試前置到開發測試環節，結合已有的功能測試、UI測試、效能測試將安全的能力融合至現有的開發體系中，發現其中可能存在注入類、反射類、通用邏輯類等安全漏洞。

3.3 API資料識別與追蹤

敏感資料識別是API資料管理中最基礎的組成成分，傳統流量的方式是分析請求介面的過程中是否從請求或響應中透過正規表示式等匹配方式檢視傳輸過程中是否存在敏感資料。結合API資產情況形成【站點】-【介面】-【敏感資料】的敏感資料拓撲圖。

但隨著微服務架構的不斷演進和發展，傳統梳理方式獲取的資產只是獲取介面所涉及的敏感資料情況，並不能很好地實現敏感資料全流程跟蹤。

透過IAST的插樁方式，一方面可以透過Agent+流量的方式實時發現請求響應、API互動中存在的敏感資訊，結合AI自適應引擎提取敏感資料傳輸過程中的引數、方法特徵，獲取敏感資料的同時結合企業實際要求實現敏感自動分類分級，另一方面結合汙點追蹤技術，可實現自定義敏感資料型別、自定義鑑權介面規則、自定義特定方法呼叫規則等敏感資料識別自定義，實現對任意資料型別的標記和追蹤以及企業合規自查。具體實現方法是透過探針在資料傳輸過程中將識別的內建或自定義敏感資料欄位進行標記，追蹤敏感資料傳播的底層鏈路，從敏感資料的全生命週期進行追蹤，還原敏感資訊從輸入至儲存的完整鏈路，形成【應用】-【服務】-【介面】-【資料層型別】-【輸出/儲存】的敏感資料鏈路追蹤圖。

圖3 敏感資訊鏈路追蹤

3.4 API安全防護

懸鏡首創的基於程式碼疫苗的智慧單探針技術，關鍵是將智慧風險檢測和積極防禦邏輯注入到執行時的數字化應用中，如同疫苗一般與應用載體融為一體，使其實現對潛在風險的自發現和對未知威脅的自免疫。

傳統的API資產防護方案一般採用旁路流量分析、威脅情報和WAF進行聯動防禦，而阻斷API漏洞的速度取決於三者聯動的速度，所以對於ODay漏洞的發現和阻斷效果不佳，往往很難讓人滿意。因而可以在測試階段將IAST檢測探針部署至應用中，在進行功能測試的同時發現系統中隱藏的API安全風險。當系統透過上線流程進入生產環境後，埋入的IAST檢測探針便會自動轉變為RASP防禦探針，從而將API風險發現能力轉化為API安全防護能力。

RASP將主動防禦能力注入業務應用，藉助強大的應用上下文情景分析能力，動態實時發現正在使用、隱藏以及廢棄的API資產等，可捕提並防禦各種繞過流量檢測的攻擊方式，提供兼具業務透視和功能解耦的共生主動安全免疫能力，對於ODay漏洞的發現和阻斷有很好的效果。結合IAST在測試階段發現的安全風險，可以採用RASP熱補丁的修復方式，將研發過程中存在或未及時修復的API風險進行重點防禦，實現IAST檢測與RASP防禦在API安全層面的聯動。

此外，RASP還可以透過檢測API呼叫的引數，以及檢測API呼叫的狀態持續監控自己的行為，根據內建的敏感資料分析引擎，按照指定部分敏感資料型別或自定義敏感資料特徵，在資料傳輸過程中發現並預警傳輸過程中可能存在的敏感資訊洩露，結合探針的執行態特徵，對指定敏感資料進行遮蔽、遮蓋、變形處理，從而有效防止敏感資料的洩露，從而保護API免受資料盜竊、惡意輸入和行為的影響，實現對API攻擊提供主動防禦能力。

 

2022年，Gartner釋出了《2022雲Web應用程式和API防護 魔力象限》，指出目前雲Web應用程式和API防護市場正在快速增長。面對API安全需求的激增，透過IAST探針技術在系統上線前完成資產管理、安全檢測、敏感資料發現及追蹤等安全要求，同時應用懸鏡獨有的單探針程式碼疫苗技術，在系統上線後進行API安全防護，從而實現API安全從前置左移到右移的檢測與防護全流程覆蓋。