翻譯及整理：叡揚資訊 資訊安全事業處
98% 的開發人員將 API 視為完成工作的關鍵貢獻者，86% 的開發人員計劃在 2024 年增加使用的 API 數量。API 常用於軟體應用系統進行通訊、資料交換、實作功能等的重要角色，但若沒有得到充分的保護，API 也可能使企業面臨到風險，如果您正在考慮 API 的安全性測試及如何保護 API 在不危及安全狀態的情況下又可以達到敏捷性的開發。請將本文視為成功的 API 安全行為的檢查清單。
什麼是 API 安全性？
當今的軟體應用系統離不開 API，它們通過控制程式的元素來交互實現各種應用系統和軟體系統之間的無縫接軌。從資料庫和伺服器通訊的 Web API，到允許存取 API 功能的作業系統，以及提供開發人員將事先編寫好的程式碼整合到自已的 API 程式碼資料庫，API 使複雜的軟體應用系統開發變得簡單，而且增加了靈活性，並縮短開發時間。
然而，API 也有可能成為風險來源，潛在攻擊者可以使用 API 獲得未經授權的存取，如發起 DDoS 攻擊等惡意活動，並獲得立足點進行橫向移動或竊取資料。且當我們談論API 安全的含義和 API 安全最佳實務時，我們將重點放在企業用來保護 API 免受此類利用和濫用的流程和措施。
API 安全威脅的類型
API 具有獨特的漏洞和安全風險，當企業希望保持強大的安全狀態時，需要有針對性的方法。最新的 OWASP API Security Top 10 討論可能導致負面威脅影響的 API 風險。
- 物件層面的無效授權（Broken Object Level Authorization）：透過操縱 API 請求中的物件識別，攻擊者可以利用 API 端點來取得存取權限。ID 可以是連續整數和 UUID，也可以是通用字串，並且很容易識別。
- 無效的身分認證（Broken Authentication）：如果您的身份驗證機制存在漏洞，攻擊者可以利用身份驗證令牌（Token），或透過冒充合法使用者來存取您的資料。
- 物件層面屬性的無效授權（Broken Object Property Level Authorization）：這些機制分段對物件或屬性的特定部分來做存取。且未經授權的使用者利用物件屬性層級缺乏授權驗證來取得存取權限。
- 無限制的資源耗用（Unrestricted Resource Consumption ）：API 需要資源來處理請求，但是當 API 擁有無限資源時，攻擊者可以發動成功的 DDoS 攻擊，導致服務中斷並增加營運成本。
- 無效的功能權限控管（Broken Function-level Authorization ）：由於存在大量使用者、群組和角色，存取控制策略可能很快就會變得複雜。如果使用者權限系統不完整或損壞，這就為攻擊者敞開了大門。
- 無限制存取敏感業務流程（Unrestricted Access to Sensitive Business Flows ）：開發流程中過度使用敏感資訊並不是由開發者錯誤引起的，攻擊者可能會發現此開發流程，自動進行過度存取並造成損害。
- 伺服器端請求偽造（Server-side Request Forgery ）：許多企業認為 VPN 或防火牆足以提供保護。但是，如果 API 在未驗證使用者提供的 URI 的情況下取得遠端資源時，則精心設計的請求可能會傳送到計畫外的目的地。
- 安全配置錯誤（Security Misconfiguration ）：配置變更和定期管理非常重要，但每次變更都會帶來風險，特別是當開發人員不遵循 API 安全最佳實務時。
- API 資產管理不當（Improper Inventory Management ）： OWASP 提醒企業，API 比傳統 Web 應用系統暴露更多端點。因此，文件至關重要。已棄用的版本或暴露的測試端點是攻擊者輕而易舉的目標。
- 不安全的使用 API （Unsafe Consumption ）：開發人員通常信任與第三方 API 互動的端點，但眾所周知，攻擊者會追蹤與目標 API 整合的第三方服務，並從該立足點發動攻擊。
影子 API 與殭屍 API
另外兩個值得強調的 API 風險是影子 API 和殭屍 API，這兩種類型的 API 不受業務監控，並且會增加巨大的風險。
影子 API 類似於影子 IT 的概念，影子 API 是未經管控下建立的 API，通常用於小型開發人員，或未經授權或未納管。這些 API 將在業務的策略和公司治理之外建立和部署，這意味著現有的 API 安全測試工具無法監控它們。無法保證影子 API 具有必要的身份驗證和存取，並且由於安全團隊和企業不知道它們，因此它們可能會讓您的企業面臨資料外洩或隱私風險。
殭屍 API 面臨類似的挑戰，但它們的存在方式不同。殭屍 API 是一種尚未停用的 API，可能是因為開發團隊已將其更新到新版本，並且要麼忘記了它的存在，要麼認為最好保持其運行以確保更新不會出現問題。您可能已經忘記了公開的 API 或 API 端點，但攻擊者非常樂意為您記住它們。
API 攻擊的影響是什麼？
為了了解風險，讓我們考慮一下威脅者利用 API 漏洞後會發生什麼情況的一些範例。
- 敏感資料暴露
- API 負責個人資訊處理，包括醫療保健詳細資訊、金融交易和 PII。由第三方開發者和應用系統使用，維護 API 安全應該是維護消費者信任和確保監管合規性的首要任務。
- 未經授權的訪問
- 一旦攻擊者透過您的 API 漏洞建立立足點，他們進行惡意破壞的機會就將是無限的。威脅行為者可能會注入惡意軟體或勒索軟體、發動中間人攻擊、執行程式碼注入或進行橫向移動以存取企業的寶貴資產。
- DDoS 攻擊
- 特別是當 API 資源不受限制時，它們可能成為分散式阻斷服務 （DDoS） 攻擊的目標，其中 API 充斥著流量和通訊請求，導致合法使用者無法使用。這些資訊可以從多個來源發送，從而增加了攻擊的影響。
如何利用 API 安全最佳實務防禦 API 攻擊
保護 API 需要採取多方面、分層的方法。首先了解您環境中 API 風險的真實程度，然後在開發週期中儘早實施控制措施來識別和修復漏洞。如果您正在尋找 API 安全檢查表，最佳實務包括：
- 實施強而有力的控制：有許多核心安全措施需要儘早實施。多重身份驗證可以防止攻擊者存取您的 API，即使他們竊取了憑證。 OAuth 或 JWT 等強大的身份驗證也可以將攻擊者拒之門外。如果強制執行速率限制，暴力攻擊就會困難得多。當然，始終使用資料加密來使資料更難以被竊取。
- 確保所有 API 的可視性：無論您的文件管理有多完整，都可能會發生您看不到的 API，而您的 API 安全測試工具無法保護它們看不到的內容。尋找一個能夠提供單一整體視圖的解決方案，包括內部、外部、第三方、託管、非託管、影子和殭屍，並提供詳細訊息，例如 ： 它們的使用方式以及隨著時間的推移所做的更改。
- 鼓勵開發人員限制攻擊面：API 的好處之一是它們可以在不同的專案中重複使用，但許多開發人員擔心修改現有 API，因此他們從頭開始 — 無意中增加了攻擊面。使用提供歷史 API 可視性的工具可以使開發人員改變返回編碼板的想法。
- 儘早持續驗證 API：對於 API 安全性，左移至關重要。當從一開始就掃描 API 文件和程式碼時，安全性就會納入設計階段，團隊可以發現錯誤配置以及路徑定義、驗證模式和傳輸加密中的風險。然後可以將文件與實施進行比較，以快速且不間斷地識別任何問題。
在 Checkmarx，我們專注於將 API 安全性左移並往右集成，在程式碼層級發現和驗證每個 API，以便在軟體開發生命週期中儘早識別和緩解問題，然後與解決方案集成，例如 ： DAST，以便客戶可以即時保護即時 API。
與許多其他解決方案不同，Checkmarx API 安全性提供完整的 API 可視性，以便企業可以準確、即時地了解整個 API 攻擊面，包括影子 API 和殭屍 API，所有這些都來自單一全域 API 資料庫。
為了實現必要的開發速度並降低持續的 API 風險，Checkmarx 包含完整的變更日誌，使開發人員能夠毫不猶豫地利用和重新利用現有的 API。
此外，在確保 API 安全性方面，Checkmarx 還可以識別 API 中的漏洞，例如跨站腳本攻擊、SQL 注入等攻擊手法。
透過單一解決方案，安全和營運團隊可以全面了解所有應用系統安全風險，並提供優先修復指引，以集中精力緩解最關鍵的問題。開發人員可以確信他們的 API 符合行業標準和公司治理，並且他們正在促進敏捷性開發和創新設計。