API（應用程序編程接口）可以定義為一組指令，用代碼編寫，允許通過 Internet 在軟件之間進行通信。API 已成為整個 DevOps 流程的關鍵組成部分，不僅允許軟件和服務器之間通過 Internet 進行無縫集成和通信，而且還改進了整個 DevOps 流程并允許相對輕松地構建更復雜的軟件。使用 API 所取得的成功見證了其使用率和流行度的飆升，尤其是在過去 12 個月中。

昨天的 API 攻擊與今天的 API 攻擊

由于 API 越來越受歡迎，它們已成為網絡攻擊的重點。僅在過去 12 個月中，API 攻擊流量就增長了 681%，95% 的公司根據研究報告報告了 API 安全事件。API 攻擊可以描述為出于惡意目的濫用或非法使用或嘗試使用 API，通常是為了非法訪問服務器以泄露數據或導致服務中斷。

過去，API 攻擊主要依賴于針對已知漏洞，例如 SQL 注入攻擊和 XSS 攻擊。如今，API 攻擊要復雜得多——不良行為者會戳戳刺探以了解公司 API 中的業務邏輯漏洞并瞄準這些漏洞。

昨天的 API 攻擊是如何運作的？

由于 API 充當軟件之間通過 Internet 進行通信的網關，因此它們通常存儲有關實現方法及其結構的敏感信息。當攻擊者獲得此信息的訪問權限時，它可用于發起網絡攻擊，尤其是利用已知 API 漏洞或配置不當的 API 的攻擊。因此，當濫用 API 的漏洞導致未經授權的訪問或數據泄漏時，API 攻擊就會起作用。

已知 API 漏洞的類型以及如何防范它們

SQL 注入攻擊——SQL 注入攻擊使用特制的惡意 SQL 代碼通過 SQL 數據庫插入輸入字段，以潛在地訪問不打算顯示的信息。代碼開發不良的應用程序更容易受到 SQL 攻擊。

XSS 注入攻擊——與 SQL 攻擊類似，跨站點腳本 (XSS) 攻擊使用惡意制作的 JavaScript 代碼插入輸入字段，以潛在地訪問數據庫并非法訪問信息。同樣，當軟件開發不當時，也會發生 XSS 攻擊。

推薦

應實施輸入驗證。輸入驗證確保用戶輸入與預期參數匹配。這些可以防止 SQLi 和 XSS 攻擊。

其他類型的 API 攻擊

如今，大多數攻擊的目的是通過利用 API 漏洞獲得對服務器的未授權訪問，隨后導致服務中斷或數據被盜。針對 API 的一些最常見的攻擊是：

DDoS 攻擊

當攻擊者通過同時請求數千個連接來淹沒 API 的內存時，就會發生針對 API 的分布式拒絕服務 (DDoS) 攻擊。目的是通過使可用資源無法訪問來淹沒內存并導致服務中斷。雖然 DDoS 攻擊不會導致信息泄露，但它們的目的是阻撓。

建議——應監控、過濾和驗證所有入站流量。還應實施速率限制。

中間人攻擊 (MiTM)

當攻擊者偷偷攔截、中繼和/或修改兩個客戶端之間的請求或通信時，就會發生中間人攻擊。對于 API，攻擊者可以攔截會話令牌發布 API 和 HTTP 標頭與用戶之間的通信。這可能會授予攻擊者對用戶帳戶的訪問權限，從而可能導致數據和個人信息被盜。

建議——所有網絡通信都應使用 TLS 加密。TLS 確保連接保持私密，每個連接都有一個唯一生成的加密密鑰。

資產管理不當

當有不止一種方法訪問應用程序數據庫環境時，就會發生這種類型的 API 攻擊。通常，在應用程序的生產狀態期間，多個 API 端點連接到生產環境；當這些端點被遺忘且未被刪除時，攻擊者就有機會使用它們發出 API 請求并可能獲得對敏感數據的訪問權限。

建議——應正確記錄生產階段使用的所有 API，以便刪除多余的 API 以防止未經授權的訪問。

通信加密不佳

傳輸層安全 (TLS) 為 Internet 上的數據傳輸提供最基本的加密形式。這確保了傳輸的數據無法以純文本形式讀取，從而在傳輸敏感數據時增加了一層安全性。加密不當的流量可能導致 MiTM API 攻擊。

建議——TLS 應該跨網絡使用，因此網絡流量是加密的，因此在 MiTM 攻擊的情況下，攻擊者無法讀取數據。

過多的數據暴露

Web 應用程序使用 API 定期處理和傳輸敏感數據。因此，可能會發生數據泄露，通常是在 API 未在響應到達客戶端之前對其進行過濾時。數據泄露可能導致未經授權訪問信用卡信息、會話令牌、密碼、私人健康信息等信息。

建議——應過濾和驗證所有 API 調用和響應，以便只允許授權的請求和響應通過。

損壞的用戶身份驗證

API 認證是一項核心服務，用于識別和授權客戶端訪問應用程序。當會話和憑證管理都存在弱點時，就會發生用戶身份驗證失敗的情況。這可能導致身份驗證令牌被盜，進一步使攻擊者能夠使用它們來暴力破解 Web 應用程序或獲得未經授權的訪問。

建議——API 開發人員應確保在構建 API 時符合正確的標準，并且應避免使用 API 密鑰進行用戶身份驗證。還應實施多因素身份驗證。

損壞的對象級別授權

損壞的對象級別授權是一種不安全的直接對象引用。當未正確設置對象級權限時會發生這種情況，導致使用用戶輸入功能對資源進行未經授權的訪問。

建議——應適當管理用戶授權，特別是對于整個身份驗證過程中的登錄用戶。

批量分配

當用戶可以通過利用特制請求來包含對應用程序功能產生不利影響的參數來覆蓋服務器端變量時，就會發生批量分配。當請求主體被解析為對象或利用某些框架級別的自動綁定功能（如 Spring 和 .NET）時，可能會發生批量分配。

建議——開發 API 時不應使用自動綁定功能。此外，限制可由客戶端修改的屬性。這可以防止將請求主體解析為對象。

參數篡改

當攻擊者操縱在服務器和客戶端之間交換的參數（通常存儲在 cookie、隱藏的表單字段或 URL 查詢字符串中）以修改或竊取應用程序數據時，就會發生參數篡改。

建議——Web 應用防火墻可以防止參數篡改。將應用程序輸入的格式列入白名單并加密會話 cookie 也有助于防止參數篡改。

結論

隨著 API 繼續被組織和個人廣泛用于軟件開發和集成，有必要了解與使用 API 相關的風險。這些風險主要與與 API 相關的漏洞一致。雖然幾乎不可能完全保護 API 免受所有可能的攻擊形式，但了解針對 API 的眾所周知且頻繁的攻擊不僅有助于拓寬您對它們的理解，還可以讓組織在緩解這些攻擊時做出正確的決定。