2.2 API安全漏洞類型

在發生的API安全事件中，導致問題發生的漏洞機理和原因與傳統Web安全相似，并有大量的交叉地帶，API安全的很多漏洞類型與傳統Web安全非常類似。

2.2.1 常見的API安全漏洞類型

根據安全漏洞發生的機理和原因，對API安全漏洞做歸類分析，常見的類型如下。

■ 未受保護API：在現行的Open API開放平臺中，一般需要對第三方廠商的API接入身份進行監管和審核，通過準入審核機制來保護API。當某個API因未受保護而被攻破后，會直接導致對內部應用程序或內部API的攻擊。比如因REST、SOAP保護機制不全使攻擊者透明地訪問后端系統即屬于此類。

■ 弱身份鑒別：當API暴露給公眾調用時，為了保障用戶的可信性，必須對調用用戶進行身份認證。因設計缺陷導致對用戶身份的鑒別和保護機制不全而被攻擊，比如弱密碼、硬編碼、暴力破解等。

■ 中間人劫持：因API的通信鏈路安全機制不全，攻擊者通過攻擊手段將自己成為API鏈中的某個受信任鏈，從而攔截數據以進行數據篡改或加密卸載。此類攻擊，通常發生在網絡鏈路層。

■ 傳統Web攻擊：在這里主要是指傳統Web攻擊類型，通過攻擊HTTP協議中不同的參數，來達到攻擊目的，比如SQL注入、LDAP注入、XXE等。而攻擊者在進一步攻擊中，會利用權限控制缺失、CSRF進行橫向移動，從而獲取更大的戰果。

■ 弱會話控制：有時API身份鑒別沒有問題，但對會話過程安全保護不足，比如會話令牌（Cookie、一次性URL、SAML令牌和OAuth令牌）的保護。會話令牌是使API服務器知道誰在調用它的主要（通常是唯一的）方法，如果令牌遭到破壞、重放或被欺騙，API服務器很難區分是否是惡意攻擊行為。

■ 反向控制：與傳統的交互技術不同，API通常連接著兩端。傳統的應用中大多數安全協議都認為信任服務器端是可信的，而在API中，服務器端和客戶端都不可信。如果服務器端被控制，則反向導致調用API的客戶端出現安全問題，這是此類安全問題出現的原因。

■ 框架攻擊：在API安全威脅中，有一些特殊存在的攻擊場景，它們是API規范、架構設計導致的安全問題，這類威脅統稱為框架攻擊。最常見的比如同一API存在不同版本，導致攻擊者攻擊低版本API漏洞；同一API的不同客戶端調用，可能PC端沒有安全問題而移動端存在安全問題等。

2.2.2 OWASP API安全漏洞類型

在API安全發展的過程中，除了各大安全廠商和頭部互聯網企業在奔走呼吁之外，還有一家公益性安全組織，即開放式Web應用程序安全項目（Open Web Application Security Project，OWASP）。OWASP是一個開源的、非盈利的全球性安全組織，主要致力于應用軟件的安全研究，它有很多開源項目，OWASP API安全Top 10就是其中的一個。

在OWASP API安全Top 10中，OWASP延續了Web安全的傳統，收集了公開的與API安全事件有關的數據和漏洞獵人賞金平臺的數據，由安全專家組進行分類，最終挑選出了十大API安全漏洞的類型，以警示業界提高對API安全問題的關注。這十大API安全漏洞類型的含義分別如下。

■ API1-失效的對象級授權：攻擊者通過破壞對象級別授權的API，來獲得未經授權的或敏感的數據，比如通過可預測訂單ID值來查詢所有訂單信息。

■ API2-失效的用戶認證：開發者對API身份認證機制設計存在缺陷或無保護設計，導致身份認證機制無效，比如弱密碼、無鎖定機制而被暴露破解、Token未校驗或Token泄露導致認證機制失效等。

■ API3-過度的數據暴露：在API響應報文中，未對應答數據做適當的過濾，返回過多的、不必要的敏感信息。比如查詢用戶信息接口時卻返回了身份證號、密碼信息；查詢訂單信息時也返回了付款銀行卡號、付款人地址信息等。

■ API4-缺乏資源和速率控制：在API設計中，未對API做資源和速率限制或保護不足，導致被攻擊。比如用戶信息接口未做頻次限制導致所有用戶數據被盜；文本翻譯接口沒有速率限制導致大量文件上傳耗盡翻譯服務器資源。

■ API5-失效的功能級授權：與API1類似，只不過此處主要指功能級的控制，比如修改HTTP方法，從GET改成DELETE便能訪問一些非授權的API；普通用戶可以訪問api/userinfo的調用，直接修改為api/admininfo，即可調用管理類API。

■ API6-批量分配：在API的業務對象或數據結構中，通常存在多個屬性，攻擊者通過篡改屬性值的方式，達到攻擊目的。比如通過設置user.is_admin和user.is_manager的值提升用戶權限等級；假設某API的默認接口調用參數為{"user_name":"user"，"is_admin":0}，而惡意攻擊者修改請求參數，提交值為{"user_name":"attacker"，"is_admin":1}，通過修改參數is_admin的值來提升為管理員權限。

■ API7-安全性配置錯誤：系統配置錯誤導致API的不安全，比如傳輸層沒有使用TLS導致中間人劫持；異常堆棧信息未處理直接拋給調用端導致敏感信息泄露。

■ API8-注入：與OWASP Web安全注入類型相似，主要指SQL注入、NoSQL注入、命令行注入、XML注入等。

■ API9-資產管理不當：對于API資產的管理不清，比如測試環境的、已過期的、低版本的、未升級補丁的、影子API等接口暴露，從管理上沒有梳理清楚，導致被黑客攻擊。

■ API10-日志記錄和監控不足：對API缺失有效的監控和日志審計手段，導致被黑客攻擊時缺少告警、提醒，未能及時阻斷。比如沒有統一的API網關、沒有SEIM平臺、沒有接入Web應用防火墻等。

OWASP API安全Top 10的發布，第一次在公眾視野中理清了API安全的常見問題類型，同時也從API生命周期管理、縱深防御的安全設計思想上，為API安全的綜合治理提供了指導方向。當然，作為API安全的第一個版本，也會有它的不足，比如筆者認為API1與API5對問題成因的闡述，沒有傳統的Web安全中對水平越權、垂直越權的描述清晰，容易導致問題歸類劃分的混亂，但仍有理由相信，OWASP API安全Top 10對業界的重大意義，未來的版本發布更值得期待。