API(Application Programming Interface)應用程序接口，可以應用于所有計算機平臺和操作系統，以不同的格式連接數據調用數據。比如，用戶可以跟蹤電商平臺購買的貨物位置，就是電商平臺與物流公司之間使用了API位置實時調用產生的效果。

許多組織更關注于快速的API和應用程序交付，而忽視了API安全保護，這也是近幾年來API攻擊和數據泄露的主要原因。本文將從API常見類型、API攻擊、API安全測試、API安全建設這幾個角度做簡單分享。

常見API類型

API攻擊

說到API攻擊不得不說，開放式Web應用程序安全項目(OWASP)的非營利組織，多年來應用安全十大排名在安全行業中經常被引用。

在2019年，OWASP發布了API Security Top 10，描述了十個最常見的API缺陷。

它作為培訓和提高認識的輔助工具非常有用，也可以作為一個輕量級的分類標準，對API中的問題進行分類，下面將從用例和預防展開說明。

1.API1:2019-失效的對象級別授權

攻擊者在 API 調用中將自己資源的ID替換為屬于另一個用戶的資源的 ID。缺乏適當的授權檢查允許攻擊者訪問指定的資源。這種攻擊也稱為IDOR(InsecureDirect Object Reference)。

用例：

• API 調用參數訪問的資源 ID /api/id1 /financial_info。
• 攻擊者將其資源的 ID 替換為猜測的另一個ID /api/id2/financial_info。
• API 不檢查權限并允許調用通過。
• 如果可以枚舉ID，問題會更加嚴重/api/000-999/financial_info。

預防：

• 基于用戶策略和繼承關系來實現適當的授權機制。
• 不要依賴客戶端發送的ID，改用存儲在會話對象中的ID。
• 檢查每個客戶端訪問數據庫的請求授權。
• 使用無法猜測的隨機 ID (GUID)。

2.API2:2019-失效的用戶身份驗證

較弱的API身份驗證允許攻擊者冒充其他用戶的身份。

用例：

· 被視為“內部”的未受保護API· 弱密碼、純文本密碼、弱哈希密碼、共享密碼或默認密碼· 缺失驗證碼或沒有賬號鎖定機制，攻擊者可以對同一用戶賬號進行暴力破解· URL中包含令牌憑證和密碼· 接受未簽名或弱簽名的JWT令牌(“alg”:“none”)，或未校驗令牌過期時間。

預防：

· 檢查所有可能的方式來對所有API進行身份驗證· 使用標準身份驗證、令牌生成、密碼存儲和多因素身份驗證 (MFA)· 使用短期訪問令牌· 驗證您的應用程序(以便知道誰在與您交談)· 對身份驗證使用更嚴格的速率限制，并實施鎖定策略和弱密碼檢查· 使用OWASP Authentication Cheat Sheet(身份驗證備忘單)https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md。

3.API3:2019-過度的數據暴露

API可能會暴露比客戶端合法需要之外的更多數據。

用例：

• API返回完整的數據對象，因為它們存儲在后端數據庫中。
• 客戶端應用程序過濾響應并僅顯示用戶真正需要查看的數據。
• 攻擊者直接調用API并獲取被過濾掉的敏感數據(嗅探抓包)。

預防：

• 永遠不要依賴客戶端過濾數據!· 檢查API的響應，確認其中僅包含合法數據· 仔細定義所有API響應的模式· 識別所有敏感數據或個人身份信息 (PII)，確認其使用的合理性· 執行schema-based響應驗證機制作為額外的安全措施。這種機制定義并強制檢查所有方法返回的數據，包括錯誤信息。

4.API4:2019-資源缺乏和速率限制

API無法防止過多的調用和載荷大小。攻擊者會使用拒絕服務 (DoS)，造成API無響應或不可用。

用例：

• 攻擊者通過發送超出其處理能力的請求來使API過載和阻塞。
• 請求時某些字段超出API可以處理的范圍。

預防：

• 定義適當的速率限制· 限制有效載荷大小· 添加對壓縮比的檢查· 定義容器資源的限制(內存、CPU、文件描述符和進程)。

5.API5:2019-失效的功能級授權

攻擊者找出“隱藏”的管理API方法并直接調用它們。

用例：

• 一些管理功能作為API公開，如果非特權用戶知道，他們可以在未經授權的情況下訪問這些功能。
• 可以是發掘的URL，或者使用不同的參數/api/users/my_financial_info —> /api/admin/all_info。

預防：

• 默認拒絕所有訪問。
• 確保所有管理控制器都從管理抽象控制器繼承，抽象控制器根據用戶的組/角色實施授權檢查，只允許對屬于相應組或角色的用戶進行操作。
• 正確設計和測試授權。

6.API6:2019-批量分配

在API中容易利用批量分配，因為，它們通過設計公開了應用程序隱含的實現方法以及屬。

性名稱。現代框架鼓勵開發人員使用來自客戶端的輸入自動綁定到代碼變量和內部對象中的功能。攻擊者可以使用這種方法來更新或覆蓋開發人員從未打算公開的敏感對象屬性。

用例：

攻擊者可以通過仔細閱讀配套文檔，來推測出對象的屬性、查找到不同的 API 端點、或在請求負載中發掘額外的屬性，進而對它們進行篡改。

· 與權限相關的屬性：user.isadmin、 user.isvip僅應由管理員設置· 與流程相關的屬性：user.cash僅應在付款驗證后在內部設置· 內部屬性：article.created_time僅應在應用程序內部設置。

預防：

• 不要自動綁定傳入數據和內部對象。
• 僅將客戶端可更新的屬性列入白名單。
• 使用內置功能將客戶端不應訪問的屬性列入黑名單。
• 在設計時精確定義在請求中接受的模式、類型，并在運行時強制執行它們。

7.API7:2019-安全配置錯誤

API 服務器的不良配置允許攻擊者利用它們

用例：

• 缺少最新的安全補丁，或者系統已經過期。
• 未受保護的文件和目錄。
• 缺少傳輸層加密，使用過時或配置錯誤的TLS。
• 暴露存儲或服務器管理面板。
• 缺少CORS(跨域資源共享)策略或安全標頭。
• 帶有堆棧跟蹤的錯誤消息。
• 啟用了不必要的功能。

預防：

• 在所有環境中持續評估配置和設置有效性的自動化過程。 為了防止異常追蹤和其他有價值的信息被傳回攻擊者，如果可以，定義和強制使用統一的API響應格式，包括錯誤信息。
• 禁用不必要的功能。
• 限制管理訪問。

8.API8:2019-注入

攻擊者通過任何可用的注入方法(如，直接輸入、參數、集成服務等)向API提供惡意數據，并期望這些惡意數據被發送至解釋器執行。

用例：

• 攻擊者發送惡意輸入以轉發給內部解釋器。
• SQL· NoSQL· LDAP· 操作系統命令· XML外部實體。

預防：

• 永遠不要相信你的 API 消費者，即使他們是內部的。
• 嚴格定義所有輸入數據，例如模式、類型和字符串，并在運行時強制執行。
• 驗證、過濾和清理所有傳入數據。
• 定義、限制和強制執行 API 輸出以防止數據泄漏。

9.API9:2019-資產管理不當

攻擊者通過發現API的非生產版本(例如，臨時的、測試版或更早期的版本)，他們沒有如生產環境API那樣受到良好保護，將通過這些渠道進行發起攻擊。

用例：

• DevOps、云、容器和 Kubernetes 使多個部署變得容易(例如，開發、測試、分支機構、舊版本等)。
• 為了保持向后兼容性，迫使舊的API繼續運行。
• 舊版本或非生產版本未得到適當維護，但這些端點仍然可以訪問生產數據。
• 一旦通過一個端點進行身份驗證，攻擊者可能會切換到生產端點。

預防：

• 保持所有API主機的最新清單和未知API的能力。
• 限制不應對外公開的任何訪問。
• 限制對生產數據的訪問，并隔離生產和非生產數據之間的訪問。
• 實施API網關和安全檢測產品。
• 淘汰舊版本的API或舊版本程序安全修復。
• 實施嚴格的身份驗證、重定向、CORS 等。

10.API10:2019-日志和監視不足

缺乏適當的日志記錄、監控和警報會導致攻擊和攻擊者被忽視。

用例：

• 日志不受完整性保護(沒有生成任何日志、日志級別沒有正確設置、或日志消息缺失足夠的細節信息)。
• 日志未集成到安全信息和事件管理 (SIEM) 系統中。
• 日志和警報設計不佳。
• 公司依賴手動而不是自動化系統。

預防：

• 記錄失敗的嘗試、拒絕訪問、輸入驗證失敗或安全策略檢查中的任何失敗。
• 確保對日志的標準化，以便其他工具也可以使用。
• 包括足夠的細節來識別攻擊者。
• 避免在日志中包含敏感數據，如果需要這些信息用于調試目的，請對部分信息進行脫敏處理。
• 與SIEM以及其他監控和警報工具集成。

中文詳細參考鏈接：

http://www.owasp.org.cn/OWASP-CHINA/owasp-project/OWASPAPITop102019.pdf

API安全測試

在左移的API安全實踐中，一個重點是確保構建管道的安全，需要企業將安全工具嵌入持續集成/持續交付(CD/CD)中，以及基于git的開發人員工作流程中。以下列出了兩類安全測試工具。

1.靜態應用安全測試(StaticApplication Security Testing，SAST)

用于分析原始代碼的潛在弱點和漏洞，通常在代碼被提交到版本控制或構建階段時運行。

GitHub code scanning、Coverity Scan Static Analysis、reshift、Xanitizer、HCL AppScan CodeSweep

2.動態應用安全測試(DynamicApplication Security Testing,DAST)

用來分析運行中的應用，以發現可利用的漏洞，通常在生產交付前啟動，或在生產中持續使用。

開源軟件：OWASP ZAP、StackHawk、Arachni、sec-helpers、OWASPPurpleteam。

缺點：當然以上工具也有其弱點，比如SAST工具誤報率會較高，涉及人工復核成本。DAST工具運行時間會較長，需提前預留時間，以免耽誤發布。

需要承認的是掃描器工具并不能用來檢測所有類型的問題，比如一些濫用的業務邏輯缺陷。

來源參考：

https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools

API安全測試實踐

1.API安全測試的小技巧

• https://github.com/inonshk/31-days-of-API-Security-Tips
• https://cloud.tencent.com/developer/article/1805577

(以上鏈接的中文翻譯)

2.開發安全的API所需要核對的清單

• https://github.com/shieldfy/API-Security-Checklist/blob/master/README-zh.md

API安全建設思考

架構設計對于有效的保護API安全至關重要，架構中需要具備捕獲和分析所有API流量的產品。

需要有豐富的數據引擎、基于API Security Top10威脅、算法識別等技術來檢測暴露的分析，并進行有效的攔截，以及提供加固補救措施。

流程和人員設計同樣重要，在發現、測試和保護API時，補救措施以及各內部角色和第三方組織的協同。

1.安全產品與環境無關

需要支持現代云架構和傳統的基礎設施架構。

2.API資產和攻擊檢測能力

由于API發開、API集成和第三方API依賴，使得API清單不斷發展，必須有不斷識別API端點和參數(不僅是IP和主機名，還需要功能、路徑、信息主體)，未知影子API，過期或者廢棄的僵尸API。特別是敏感數據發現能力，比如個人身份信息，因為這塊會涉及監管合規問題。持續檢測數據權限、口令認證等缺陷，并能及時感知API的攻擊存在。

3.集成能力

能夠與負載均衡、API網關、WAF、漏洞管理平臺(VM)、DevOps套件、ITSM等平臺集成。

4.API代碼分析

在生產交付前掃描可能存在的缺陷，以減少攻擊者發現可利用條件的可能。

5.人員能力

API安全專業知識可能分散在開發、基礎設施、運營、安全或者API產品團隊中，需要去梳理，以便在發現、測試、保護和事件響應方面進行合作。