新的安全威脅：API安全的挑戰和應對策略|首屆API安全管理論壇 - 網安

12月3日，由永安在線舉辦的首屆API安全管理論壇在深圳舉辦。四位大咖圍繞API面臨的挑戰及如何進行API安全管理進行了精彩分享。其中，騰訊技術工程事業群安全專家胡珀在論壇上作了主題為《新的安全威脅：API安全的挑戰和應對策略》的分享，我們對現場演講全文進行了梳理，以供更多關注API安全管理的人共同學習。

演講全文：

我先做一個自我介紹，我叫胡珀，是來自騰訊 TEG安全平臺部，有超過 15 年的網絡安全經驗，在 07 年大學畢業之后，就加入到騰訊安全平臺部，然后一直在從事基礎安全體系方面的工作。

大家都知道，07年是 Web 2.0 的時代， Web 2.0時代的最大的問題 Web 安全，而Web API 安全就是Web安全中的一大類。從 07 年開始，我們已經在研究這方面的工作，只是最近幾年才把API安全單拎出來講。今天就將API安全這部分給大家做一個分享，也是我們團隊以及我個人的一點經驗之談。

下面我將從三個方面來分享，一是API 的概念，二是風險案例，最后是安全實踐。

API的起源

API 的起源得從1940 年開始。我在維基百科上考古了一下，其實在1940 年的英國，他們以前的代碼不是現在這樣打，而是在子彈上打孔。他當時他們用了個文件柜，把這種打孔的程序放到里面去，然后有一個目錄告訴調用者，你這個東西放在哪個柜子里面，是哪個顏色袋子什么樣的東西，他們把這東西叫做 API ，這是我們目前能找到的API最老的起源，大家可以去維基百科上詳細一下。

其實1940年和現在的對 API 定義是一致的。所以說我們認為它不是一個新的概念，它只是經過幾十年的技術的演進，到了今天的樣子。下面，我們可以看一下 API 的一些定義，它其實是定義成一種函數協議，數據結構就明確主要是給調用者一個使用的。

API 其實會分很多類。比如說 90 年代到2000年左右那個時候 Windows 程序比較多，例如mqc，這種 API 其實就是一種 API 函數，在 Windows 下面。再比如說后來驗證中經常出現的數據庫，dbc這種，還有操作系統的 API 。我們現在說的最多的包括今天我們主題講的甚至整個行業里面探討的 API ，其實是指基于 Web 應用的API ，在網上的一個報告中顯示， API 的增長速度非常快，在2021 年可以看到它比上一年度是同比增長了39%。

Web2.0時代，其實它是一個奠基的時代，那個時候已經有 API 了。我們來分享一些案例。當年在QQ 空間其實已經大量使用了 API 的技術，并且有一些 API 的安全風險，也有人利用這些 API 來做些事情。然后到 2010 年移動互聯網時代，移動互聯網時代有一個特點，就是 PC 端向終端演進，這個時候催生了大量的交互技術，比如說過去我的 Web2.0里面可能我用的是ASP、PHP ，這種動態的服務端程序。但是在2010 年之后，移動端其實是會大量使用類似ajax的，既然是 ajax ，肯定會有一個 API 跟他對接，這個時候API就大量的發展。然后在2020 年之后，像云原生、大數據、物聯網包括這種微服務， DevOps 的這種里面它會提倡微服務，就更加會有大量的互相之間調用API。

導致API安全形勢嚴峻的四個原因

再回到我們為什么要關注 API這個問題？很簡單，因為公司現在有大量的 API ，所以我們就必須去關注它。同時，API安全的形勢目前也比較嚴峻。這主要由四個因素導致：

一是外國黑客緊盯。為什么呢？因為 API 它其實承載了大量重要的數據，這種情況自然會被黑客攻擊。

第二是能力沉淀不足。其實我們程序員開發同學他在編碼的時候，很多時候他可能就沒想到這個 API 是我要特殊對待的，這個時候就會出問題了。

第三是API 的治理功能還沒有跟上。因為業務發展很快，安全不一定跟得上，比如說公司大量使用 API 的時候，可能我們的安全團隊還在解決 SQL 注入的問題，還沒想過解決數據安全的問題，還在做反入侵、HS，這個時候根本就沒想到 API 怎么還會出問題。這其實就體現了 API 的治理能力沒跟上。此外，API 其實可以分成兩類，一類我理解是在互聯網上能夠公開訪問的，就是給到用戶端可以交互的，這是一類。第二類是在系統內部、服務之間，也就是一類所謂的東西流向之間，微服務之間這樣的 API ，這兩個需要用不同的方法來解決。

最后是自身安全機制問題，在設計時未考慮到安全。據一些調查報告顯示，有 55% 的 API 其實是沒有經過安全測試的，很有可能這些企業可能根本不知道 API 要單獨測試，沒想過這個問題。然后就用掃描器掃，掃完有可能根本掃不到。

我們來看一個風險案例，還是剛才我說的QQ空間的。API 它其實是一個 Web API 就是一個特殊的 cgi ，在以前很多SNS 社區 UGC 業務就大量使用這種 API 。比如 QQ 空間以前的某個業務，這個業務的一個cgi它會返回一堆 JS 代碼，里面可能會包括當前訪問的 QQ 號。這里就有一個問題，如果我在一個網頁輸出這個頁面，然后讓他去訪問JS 就可以拿到我的 QQ 號。這是一種常見的溯源手段，就是利用社交網絡的JSON Hijacking 漏洞去獲取個人信息。后面我反應過來，實際上這個就是 API 安全范疇。我們當年天天挖的漏洞就是一個 API 安全問題，它其實就是一個輸出 JSON P 格式的一個特殊的API互相之間去調用。然后 QQ 空間還有一個業務，比如說我們進入別人空間的時候，需要輸入他的問題的答案。你可能不一定知道，但是如果用這種 JSON Hijacking漏洞的話，其實也是有可能拿到答案的。

這個案例是十年以前的了，問題早就已經修復。但這些案例主要是想說明，其實 API 安全它不是一個新的概念，只是大家已經越來越重視而已。第二， API 它本質其實還是一個 cgi，傳統的安全漏洞都會出現在它上面。比如這里我舉的這個JSON Hijacking，然后還有包括SQL注入、XSS、XXE都會出現。然后還有另外的案例，比如 Facebook 的 API 爆出漏洞導致個人信息泄露。很多時候我們會通過 API 去輸出一些信息，如果你權限控制不當或者其他原因，他都能通過你的 API 把你的信息給拉走。

解決的方法前面我講過一些，可以通過傳統的方式，比如說用掃描器去掃或者用WAF來防，可以做一定緩解，但不一定全。為什么呢？比如說通過 API 泄露的一些數據，這個時候如果黑產要來拿這些數據，他一定會調集大量的機器來拖這些數據，會產生流量上的異常。或許通過流量可以發現，但是這里有個前提，就是我們大部分的WAF，可能是不會去關注這種問題的，那就解決不了問題。

第二個你得知道這個 cgi 是一個 API ，才可能會去重點關注他的流量異常。如果是一個無關緊要的，那他流量異常也沒什么問題，所以說這其實是一個挑戰。鑒權漏洞也是一樣，跟普通的其實也沒什么區別，無非就是發生在 API 上面。

還有很多新興的系統，都會使用 API 。比如說之前我們就監控到很多的蠕蟲病毒都會去攻擊某些系統的 API ，因為這些系統可能在設計之初他都沒有安全機制。包括我看到Docker API 、k8s API列出來的大部分是沒有鑒權的或是弱鑒權，默認情況下只要我能訪問到他端口，給他發這個數據去他就認，然后就會導致機器被黑或者被控制。這其實就是開發同學在設計這個系統之初可能就沒有想過我是不是去做鑒權。

還有一種就是DDOS攻擊，對 API 為什么會有DDOS攻擊呢？因為 API 它承接了很重要的業務，可能它會很消耗資源，我可能去讀的東西，但是同時 API 一般作為跟客戶端 App 的交互接口。就比如說我在 App 去拉 Web頁面的一個 cgi然后去拿到一些數據。這個 App 我不一定會用流量去拉，可能就自己寫一個接口，比如就是一個 C 代碼，我框架里面不是瀏覽器。對傳統 web 頁面，它遭到 CC 攻擊之后，可能就會下一個 JS 或者下一個驗證碼。然后讓瀏覽器去訪問，如果瀏覽器能夠執行，就說明客戶端是瀏覽器，因為 CC 攻擊端它一般不會掉瀏覽器，它一般會自己寫一個程序。這個時候如果遇到驗證碼或者是遇到JS 是沒法去解析和執行的，然后就可以判斷出誰是攻擊者或者是誰是機器人，誰是正常的人。

但是問題來了，如果我的 App 去拉這個 cgi ，這個 App 本身我是用我自己寫的程序實現的接收響應，而不是用瀏覽器。這個時候我的 App 他會認為這個 App 是個機器人，也是攻擊方，也會把它攔掉，所以說這里就有問題。所以如果針對 API 有 CC 攻擊，其實還是很難防的。因為很容易就把真實用戶給殺掉了。基于我們的一些經驗，這個其實也是一個挑戰，實際上就是傳統的防御方法不一定能夠防 API ，必須得有一定新的思路。

總結一下， API 需要關注的安全挑戰跟傳統的web完全不一樣的地方有以下幾個：一個是在設計時，就忽略了這是一個 API ，可能就沒去去專門的對它做一些安全的設計，比如它出數據的時候，我是不是要對數據進行監控，是不是要有一個閾值，比如說這個量太大了會不會有問題，這個就是 API 的服務治理難。還有就是對外的 API 怎么去識別它是一個 API ，這也是個難點。因為傳統的不管是 WAF 也好，掃描器也好，它是沒有這個功能的。

另外一個是我們內部東西向的 API 其實是很多的，然后怎么去識別和治理它，也是有問題的。還有一個就是自動化的測試難，比如說我們去測這個 web 安全，肯定是上掃描器。但是如果這個接口是個 API 的話，首先掃描器它利用爬蟲不一定能爬到這個接口，它根本不知道你的參數，各種交互它也是不知道的，既然它邏輯都跑不起來，對 API 就更沒法去跑。以上就是騰訊過去遇到的一些難點。此外也需要注意Owasp API Securiy top 10里面的風險問題，都是需要去重點關注解決的。

API安全需要關注哪些領域和關鍵點

API 要關注哪個領域？我們從網絡安全、應用安全開發和監管合規上面大概進行了分類。網絡安全上就是通信安全端需要通信加密，你不能用弱密碼。然后DDOS防護和 CC 防護特別得注意，可以重點關注CC防護。因為根據我們的經驗，黑客打這個網站，肯定會先找你一個很好資源的 API 然后再拼命的拉起這個頁面把你拉垮。有兩類情況，一類他為了打垮你，進行DDOS攻擊。第二類就是黑客在拖你的數據，然后你的服務比較脆弱扛不住了，他瘋狂地拖，就會產生DDOS的情況，這實際上是一個數據泄露的情況。

還有流量安全可以在流量層面去檢測，對 API 安全做一些發現和加固。然后應用安全層面包括我們使用 API 網關、用服務網格去治理以及用WAF。還有就是需要依托威脅情報。就像騰訊的安全體系已經那么全面，但為什么我們還要建立安全響應應急中心，做 TSC 跟白帽子交互，讓白帽子來暴漏洞？就是因為我們需要這些威脅情報來作為補充，因為不管你的這個安全體系如何的全面，如何的強大，一定會有疏漏，這個疏漏就需要找威脅情報來幫我們查缺補漏。另外一個是安全開發。現在 DevOps 很火，那就把 API 安全放進去做一個全流程的管理。然后監管合規就不細說了，現在國家對數據安全的重視程度決定了必須對 API 這種數據的輸出大家都要特別的注意。

DevOps剛才也提到，目前在騰訊內部我們也是在按各個事業群在推這種 DevOps ，就是所謂安全左移的一些方案。根據不同的事業群，他的技術架構和當前的 DevOps 的能力是每個事業群是不一樣的。在 API 安全這一部分，我們基本上還是依托于這幾個方向盡量做一些事情：計劃創建、驗證、發布響應階段。

其實跟 DevOps 的傳統的框架是一樣的，無非就是針對 API 做了一些事情，原因不過就是過去我沒有針對他。比如說我在 API 設計的時候，我要想到他必須要建全端設計怎么樣，然后編碼的時候也是一樣，API它本質上是一端代碼，它一定會出漏洞的。至于怎么弄，大家可以參考一下騰訊的代碼安全指南，這個已經開源了，大家可以去找一下參考學習以及提出更多建議。

然后就是框架。騰訊內部有一套開發框架，現在也是在推全公司來接入。我們在框架層面做了很多事情，比如從 API 產生這個階段開始，我們做了默認有鑒權，默認就可以防注入。另外一個就是那個在測試階段，因為 API 數量大，傳統的掃描器查不到，我們主要是通過流量來查。另外可以結合公司的 API 網關直接把數據給我們。再通過就流量來查缺補漏，這樣相對會比較全一點。總的來說如果想把API安全真正的阻移，一定要跟公司的基礎設施結合起來。另外一個是WAF，我們的WAF分兩類，南北向的直接在上面加一個 API 安全的功能；如果是東西向的，就跟公司的 API 網關結合。

實際上 API 服務的治理主要就是依托 API 網關。如果企業里面的 API 特別多，我建議得具備 API 網關。但前提是，你要保證所有的 API 都經過API網關。

還有另外一個是在流量層面。因為前面我也提到我們不管是 API 也好，web的 cgi 也好，其實很難把它全部爬到。這個時候在流量里面去把他們抓下來是非常重要的查缺補漏的方式。其實 API 流量監測跟傳統的流量系統沒什么大的區別，無非就是對 API 做一個單獨的定制。然后一般這種 API 的流量監測有兩種方式，一種是串聯在鏈路上，一種是旁路上，一般我們會推薦旁路。如果公司流量比較小，那串聯無所謂，但從過往經歷來說騰訊不適合串聯。同時如果你跟網關旁路對接的話，也可以讓網關把 SSL 流量加密，流量卸載掉之后，再來進行識別。大家可以看一下流量側的API發現的框架。

那對 CC 攻擊怎么辦呢？如果 CC 攻擊打這個 API 正好我的客戶端運氣不好，我又沒有調瀏覽器，那就只有先去通過一些其他特征，比如通過操作系統指紋、設備指紋或者其他辦法去識別出它到底是不是一個人或者是不是一個機器人。另外就是可以通過流量里面去自動識別它是 API ，識別到之后會針對這個 API 做安全策略，而不會給他去下驗證碼之類的。因為之前我們在沒有做這個事情的時候，有些時候 App 被攻擊之后，我們的防護系統會給他下驗證碼，結果它根本不會響應，整個業務就癱掉了。這樣子做了之后至少業務不會掛，然后我們再慢慢地去對抗這些CC攻擊。