淺談API安全的應(yīng)用

理論基礎(chǔ)


API它的全稱是Application Programming Interface，也叫做應(yīng)用程序接口，它定義了軟件之間的數(shù)據(jù)交互方式、功能類型。隨著互聯(lián)網(wǎng)的普及和發(fā)展，API 從早期的軟件內(nèi)部調(diào)用的接口，擴展到互聯(lián)網(wǎng)上對外提供服務(wù)的接口。調(diào)用者通過調(diào)用 API，可以獲取接口提供的各項服務(wù)，而無須訪問源碼，也無須理解內(nèi)部工作機制的細節(jié)。

API 它是預(yù)先定義的函數(shù)，為程序之間的數(shù)據(jù)交互和功能觸發(fā)提供服務(wù)。調(diào)用者只需調(diào)用 API，并輸入預(yù)先約定的參數(shù)，即可實現(xiàn)開發(fā)者封裝好的各種功能，無需訪問功能源碼或理解功能的具體實現(xiàn)機制。

API通常包含如下組成要素：通信協(xié)議、域名、版本號、路徑、請求方式、請求參數(shù)、響應(yīng)參數(shù)、接口文檔等。

API它是程序開發(fā)的基礎(chǔ)，特別是系統(tǒng)API函數(shù)，通過系統(tǒng)自帶的API函數(shù)可以快速實現(xiàn)程序開發(fā)的功能，現(xiàn)在高級語言也都是基于語言特性進行封裝各種便于程序開發(fā)的API接口，這樣就減少了開發(fā)者對具體功能的實現(xiàn)，只要直接調(diào)用API函數(shù)就可以快速實現(xiàn)功能了。但是API的雖然方便了開發(fā)，但是也同樣存在和暴露出很多安全的風(fēng)險問題。API的安全風(fēng)險有被直接HOOK風(fēng)險、安全漏洞風(fēng)險、安全攻擊風(fēng)險。

API安全它是由多種安全規(guī)則相互交叉，它主要表現(xiàn)是以下三部分:

信息安全：聚焦于信息保護，這種保護包括信息的創(chuàng)建、存儲、傳輸、落還、以及最終銷毀的生命周期。

網(wǎng)絡(luò)安全：解決服務(wù)兩方面問題，如何保護通過網(wǎng)絡(luò)傳播的數(shù)據(jù)流以及如何防止未授權(quán)的網(wǎng)絡(luò)。

應(yīng)用安全：確保設(shè)計和部署的應(yīng)用可以對抗攻擊、防止誤用。
















 

API安全風(fēng)險

 

API 在開發(fā)、部署過程中，不可避免會產(chǎn)生各種安全漏洞，這些漏洞通常存在于通信協(xié)議、請求方式、請求參數(shù)、響應(yīng)參數(shù)、訪問行為等環(huán)節(jié)，面臨外部、內(nèi)部威脅。例如，外部攻擊者利用API未授權(quán)訪問非法獲取數(shù)據(jù)、API參數(shù)校驗不嚴謹而被非法篡改。應(yīng)對外部威脅的同時，API也面臨著內(nèi)部威脅。

API 接口在設(shè)計之初未對 API 接口訪問頻率做限制，使攻擊者在短時間內(nèi)可以進行訪問大量 API 接口，這就產(chǎn)生了高頻訪問行為，這在很短的時間就可以完成如營銷作弊、惡意注冊等攻擊，甚至可能帶來 CC 攻擊。

OWASP梳理總結(jié)的10大API安全風(fēng)險

1、無效的對象級別授權(quán)

API傾向于暴露那些處理對象識別的端點，造成了廣泛的攻擊面訪問控制問題。在每個能夠訪問用戶輸入數(shù)據(jù)的功能中，都應(yīng)考慮對象級別授權(quán)檢查。

2、損壞的用戶身份驗證

身份驗證機制通常實施不正確，從而使攻擊者可以破壞身份驗證令牌或利用實施缺陷來臨時或永久地假冒其他用戶的身份。損害系統(tǒng)識別客戶端/用戶的能力會整體損害API安全性。

3、過度的數(shù)據(jù)泄露

開發(fā)人員傾向于公開所有對象屬性而不考慮其個體數(shù)據(jù)敏感性，依靠客戶端執(zhí)行數(shù)據(jù)過濾并顯示。

4、缺乏資源和速率限制

API一般不會對客戶端/用戶可以請求的資源大小或數(shù)量施加任何限制。這不僅會影響API服務(wù)器的性能，從而導(dǎo)致拒絕服務(wù)（DoS），而且還為諸如暴力破解之類的身份驗證漏洞敞開了大門。

5、功能級別授權(quán)損壞

具有不同層級、分組和角色的復(fù)雜訪問控制策略，以及管理功能和常規(guī)功能之間的模糊不清，往往會導(dǎo)致授權(quán)缺陷。通過利用這些問題，攻擊者可以訪問其他用戶的資源和/或管理功能。

6、批量分配

將客戶端提供的數(shù)據(jù)(例如JSON)綁定到數(shù)據(jù)模型，而沒有基于白名單的適當(dāng)屬性過濾，通常會導(dǎo)致批量分配。無論是猜測對象屬性、瀏覽其他API端點、閱讀文檔或在請求有效負載中提供其他對象屬性，都是攻擊者可以修改權(quán)限之外的對象屬性。

7、安全性配置錯誤

最常見的安全配置錯誤是不安全的默認配置、不完整或臨時配置、開放的云存儲、錯誤配置的HTTP標頭，不必要的HTTP方法、跨域資源共享（CORS）以及包含敏感信息的冗長錯誤消息導(dǎo)致的。

8、注入

當(dāng)不受信任的數(shù)據(jù)作為命令或查詢的一部分發(fā)送到解釋器時會發(fā)生注入缺陷，例如SQL、NoSQL的命令注入等。攻擊者的惡意數(shù)據(jù)可能會誘使解釋器執(zhí)行非預(yù)期的命令，或未經(jīng)授權(quán)訪問數(shù)據(jù)。

9、資產(chǎn)管理不當(dāng)

與傳統(tǒng)的Web應(yīng)用程序相比，API傾向于公開更多的端點，這使得文檔的準確性和及時更新顯得尤為重要。健康的主機和最新的API版本能夠有效減輕諸如API版本過期以及調(diào)試端點暴露之類的安全問題。

10、日志和監(jiān)控不足

日志和監(jiān)控不足，再加上事件響應(yīng)的缺失或無效集成，使攻擊者可以進一步攻擊系統(tǒng)，長期駐留，并橫向移動到更多系統(tǒng)以篡改、提取或破壞數(shù)據(jù)。大量入侵調(diào)查研究表明，檢測到入侵的平均時間超過200天，而且入侵檢測警告通常來自外部第三方，而不是企業(yè)內(nèi)部安全流程或監(jiān)控來檢測。

API安全同時在應(yīng)用安全方面除了參考借鑒OWASP安全風(fēng)險，同時在面對系統(tǒng)自帶API的一些安全漏洞，還要面臨一些系統(tǒng)API被HOOK而改變流程的風(fēng)險。這個是逆向工程的的常規(guī)實現(xiàn)方案，這個在軟件開發(fā)過程中也需要重點關(guān)注和應(yīng)對。


 

API安全測試


API安全測試主要是對其API的安全性、正確性和可靠性進行測試，以確保產(chǎn)品符合安全要求。它的測試需要包含用戶訪問、加密和身份驗證。API 安全測試從定義要測試的 API 開始。測試工具使用各種規(guī)范格式（包括 OpenAPI v2/v3、Postman Collections 和 HAR 文件）提供有關(guān) API 的輸入和輸出的信息。

API安全測試是一個很復(fù)雜的領(lǐng)域，API 的安全測試為手動、自動和混合活動帶來了新的挑戰(zhàn)。通常API安全測試需要靜態(tài)分析工具和動態(tài)分析工具相結(jié)合，在API安全測試中可以基于常見API安全漏洞如 SQL 和 OS 命令注入、授權(quán)/身份認證旁路、路徑遍歷問題和 OWASP Top 10 API 漏洞進行重點安全測試。

靜態(tài)分析工具，可以有效地識別特定于語言的軟件安全問題，或者眾所周知的注入攻擊類別，繼續(xù)對API繁重的代碼庫有效，但前提是這些工具也對用于公開這些API路由的庫和平臺進行建模。

在API安全測試的時候，也推薦使用OWASP Zap 和Postman 進行API安全測試，同時下面的幾個github是可以值得借鑒應(yīng)用的。

  1. https://github.com/roottusk/vapi


2、API endpoint爆破

https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api

3、越權(quán)的測試

https://github.com/PortSwigger/autorize

 

API安全應(yīng)用

 

API安全應(yīng)用應(yīng)重點通過API的安全漏洞，然后進行做API安全對抗方案的研發(fā)和策略制定，API安全應(yīng)用同時應(yīng)滿足機密性(確保信息只能被指定的用戶訪問)、完整性(防止未授權(quán)的創(chuàng)造、修改和刪除)、可用性(當(dāng)用戶需要訪問API時、確保是可用的)。

API安全在應(yīng)用安全方面可以重點關(guān)注語言的安全的編碼規(guī)則、熟悉軟件常見的安全漏洞、加強管理訪問API的系統(tǒng)和應(yīng)用憑證。

例如加強對一些系統(tǒng)內(nèi)部自帶的敏感操作的API函數(shù)進行保護，可用自實現(xiàn)的方式防止被直接掛鉤系統(tǒng)函數(shù)而破壞了功能流程。


API安全中在網(wǎng)絡(luò)安全方面可以重點關(guān)注防火墻、負載均衡、反向代理等并使用安全的通信協(xié)議(例如https)確保通信中數(shù)據(jù)安全。


在API安全實踐應(yīng)用中可以遵循以下的一些規(guī)則，提高API安全性。

  1. 每個 API 都應(yīng)該使用傳輸層安全(TLS)來防止數(shù)據(jù)泄露。雖然這引入了證書管理的復(fù)雜性，但現(xiàn)代平臺正在轉(zhuǎn)向集成證書解決方案以簡化采用。

  2. 對于具有已知身份的內(nèi)部用戶，API密鑰可用于簡化對API的訪問，而無需 OAuth2 的復(fù)雜性，只要密鑰得到安全管理。

3、不要將任何 API 密鑰提交到源代碼存儲庫，如有必要，請使用秘密管理解決方案。

4、使用授權(quán)中間件來標準化訪問控制并避免損壞的功能級授權(quán)漏洞。

5、確保對 API 密鑰使用精細的權(quán)限，以避免提供不必要或意外的訪問權(quán)限。

6、如果你開發(fā)的軟件有特別復(fù)雜的授權(quán)要求，請考慮使用標準庫，不要重新發(fā)明輪子并增加復(fù)雜性和維護問題。

7、使用標準授權(quán)模式降低復(fù)雜性，同時利用客戶端進行密集處理，減少給客戶端返回數(shù)據(jù)量。

8、在軟件中強化對日志記錄的實施，并確保采用標準模式，有利用后續(xù)日志信息的審查和優(yōu)化。


 

小結(jié)

 

API安全性已日漸成為了網(wǎng)絡(luò)應(yīng)用方面的主要技術(shù)需求之一。開發(fā)人員需要進一步加大對于API業(yè)務(wù)模型、分析能力、技術(shù)藍圖、以及合規(guī)性與標準化方面的深入研究與開發(fā)。

通過自動化、多樣化的API網(wǎng)絡(luò)攻擊，黑客不僅可以達到消耗系統(tǒng)資源、中斷服務(wù)的目的，還可以通過逆向工程，掌握 API 應(yīng)用、部署情況，并監(jiān)聽未加密數(shù)據(jù)傳輸，竊取企業(yè)數(shù)據(jù)。

安全架構(gòu)設(shè)計有很多的安全設(shè)計原則，比如公開設(shè)計原則、權(quán)限最小化、開放最小化、默認不信任等。所以在API安全設(shè)計過程中也可借鑒參考這些安全性原則。

在API安全中也需要重點關(guān)注下API安全的整個生命周期：設(shè)計、開發(fā)、測試、上線運行、迭代、下線。這個生命周期中會出現(xiàn)的API非法調(diào)用、API安全漏洞、API數(shù)據(jù)泄露問題。









作者：小道安全


歡迎關(guān)注微信公眾號 ：小道安全