理論基礎

API它的全稱是Application Programming Interface，也叫做應用程序接口，它定義了軟件之間的數據交互方式、功能類型。隨著互聯網的普及和發展，API 從早期的軟件內部調用的接口，擴展到互聯網上對外提供服務的接口。調用者通過調用 API，可以獲取接口提供的各項服務，而無須訪問源碼，也無須理解內部工作機制的細節。

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

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

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

API安全它是由多種安全規則相互交叉，它主要表現是以下三部分:

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

網絡安全：解決服務兩方面問題，如何保護通過網絡傳播的數據流以及如何防止未授權的網絡。

應用安全：確保設計和部署的應用可以對抗攻擊、防止誤用。

API安全風險

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

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

OWASP梳理總結的10大API安全風險

1、無效的對象級別授權

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

2、損壞的用戶身份驗證

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

3、過度的數據泄露

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

4、缺乏資源和速率限制

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

5、功能級別授權損壞

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

6、批量分配

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

7、安全性配置錯誤

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

8、注入

當不受信任的數據作為命令或查詢的一部分發送到解釋器時會發生注入缺陷，例如SQL、NoSQL的命令注入等。攻擊者的惡意數據可能會誘使解釋器執行非預期的命令，或未經授權訪問數據。

9、資產管理不當

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

10、日志和監控不足

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

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

API安全測試

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

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

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

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

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

   2. API endpoint爆破

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

   3. 越權的測試

https://github.com/PortSwigger/autorize

API安全應用

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

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

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

API安全中在網絡安全方面可以重點關注防火墻、負載均衡、反向代理等并使用安全的通信協議(例如https)確保通信中數據安全。

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

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

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

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

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

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

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

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

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

小結

API安全性已日漸成為了網絡應用方面的主要技術需求之一。開發人員需要進一步加大對于API業務模型、分析能力、技術藍圖、以及合規性與標準化方面的深入研究與開發。

通過自動化、多樣化的API網絡攻擊，黑客不僅可以達到消耗系統資源、中斷服務的目的，還可以通過逆向工程，掌握 API 應用、部署情況，并監聽未加密數據傳輸，竊取企業數據。

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

在API安全中也需要重點關注下API安全的整個生命周期：設計、開發、測試、上線運行、迭代、下線。這個生命周期中會出現的API非法調用、API安全漏洞、API數據泄露問題。