API 安全性與一般應用程式安全性有何不同？

已發表: 2023-07-19

儘管有時會混淆，但應用程式安全性和 API 安全性是兩個不同的學科。 應用程式安全性是指保護整個應用程式的安全，而 API 安全性是指保護組織用於連接應用程式和交換資料的 API 的安全性。 因此，組織必須對這兩個學科採取不同的方法。

什麼是應用程式安全性？

應用程式安全 (AppSec) 使用授權、加密和安全編碼實踐來保護資料和系統免受網路攻擊。 實施 AppSec 的組織可以降低資料外洩的風險、保護敏感資料並確保其應用程式符合行業標準。

ISACA 將 AppSec 計畫的五個關鍵組成部分定義為：

  1. 安全設計
  2. 安全程式碼測試
  3. 軟體物料清單
  4. 安全培訓和意識
  5. WAF和API安全網關和規則開發

什麼是 API 安全性？

API（即應用程式介面）安全性可保護 API 免受網路攻擊。 近年來，API 的使用呈爆炸式增長，透過支援應用程式之間的資料傳輸為組織提供了創新機會。 不幸的是，隨著 API 使用的增加，針對它們發動的攻擊也隨之增加。 Salt Security 的研究顯示，2022 年 6 月至 12 月期間，針對 API 的攻擊增加了 400%。

應用程式與 API 安全威脅

了解 AppSec 和 API 安全性之間的差異需要了解每個學科的主要威脅。 幸運的是，OWASP（一個致力於提高軟體安全性的非營利組織）提供了應用程式安全性和 API 安全性最重要威脅的完整清單。 該清單被稱為 OWASP 十大，整理了 OWASP 全球安全專家社群的信息，以確定對應用程式和 API 的最嚴重威脅。

有趣的是，雖然OWASP 在2003 年發布了十大Web 應用程式安全風險列表，但它在2019 年底才發布了十大API 安全風險列表。這種差異代表了應用程式安全和API 安全之間的另一個關鍵區別：應用程式安全性是一個公認的、這是一個經過廣泛研究的學科，經歷了許多演變階段，而 API 安全則不然。

雖然我們沒有時間進行深入分析，但值得簡要查看每個清單以了解它們有何不同，這應該告訴組織如何處理 AppSec 和 API 安全性。

OWASP 十大應用程式安全風險 (2021)

  1. 存取控制被破壞– 當未經授權的使用者可以存取受限制的資訊或系統時
  2. 加密失敗– 當第三方因加密缺乏或缺陷而在沒有特定意圖的情況下公開敏感資料時
  3. 注入– 當攻擊者嘗試以改變發送到解釋器的命令含義的方式向應用程式發送資料時
  4. 不安全的設計－與架構和設計缺陷相關的風險
  5. 安全設定錯誤– 當安全團隊配置不準確或安全控制不安全時
  6. 易受攻擊和過時的組件– 當組織未對組件進行修補時
  7. 識別和身份驗證失敗（即身份驗證損壞） ——當應用程式容易受到身份驗證攻擊時
  8. 軟體和資料完整性故障－當程式碼和基礎設施無法防止完整性違規時
  9. 安全日誌記錄和監控失敗（不充分的日誌記錄和監控） ——當組織因日誌記錄和監控程序不充分而無法偵測到資料外洩時
  10. 伺服器端請求偽造– 當攻擊者欺騙應用程式將精心設計的請求傳送到意外目的地時，即使受到防火牆、VPN 或其他類型的網路存取控制清單 (ACL) 的保護

OWASP 十大 API 安全風險 (2023)

  1. 物件層級授權被破壞– 當 API 物件（例如資料庫或檔案）沒有適當的授權控制時，會授予未經授權的使用者存取權限
  2. 驗證失效– 當軟體和安全工程師誤解 API 驗證的邊界以及如何實作時
  3. 損壞的物件屬性等級授權– 過度資料暴露和大量分配的組合：當攻擊者利用物件屬性等級的鎖定或不正確的授權。
  4. 無限制的資源消耗 –滿足 API 請求需要網路頻寬、CPU、記憶體和儲存。 服務提供者透過 API 整合提供其他資源，例如電子郵件/簡訊/電話或生物識別驗證，並按請求付費。 成功的攻擊可能會導致拒絕服務或增加營運成本。
  5. 破壞功能級授權涉及攻擊者向暴露的 API 端點發送合法的 API 呼叫
  6. 無限制地存取敏感業務流程－易受此風險影響的 API 會暴露業務流程（例如購買門票或發表評論），而不會補償如果以自動化方式過度使用該功能可能對業務造成的損害； 這不一定來自實作錯誤。
  7. 伺服器端請求偽造 –當 API 在未驗證使用者提供的 URI 的情況下取得遠端資源時； 使攻擊者能夠強制應用程式將精心設計的請求發送到意外的目的地，即使受到防火牆或 VPN 的保護也是如此。
  8. 安全配置錯誤－API 和支援它們的系統通常包含複雜的配置，以使其更具可自訂性。 軟體和 DevOps 工程師可能會錯過這些配置，或不遵循有關配置的安全最佳實踐，從而為不同類型的攻擊打開了大門。
  9. 不正確的庫存管理– API 比傳統 Web 應用程式公開更多端點，因此正確且更新的文件非常重要。 充足的主機和已部署的 API 版本清單對於緩解諸如已棄用的 API 版本和暴露的調試端點等問題也至關重要。
  10. API 的不安全使用－開發人員傾向於信任從第三方 API 接收的數據，而不是使用者輸入，並採用較弱的安全標準。 為了破壞 API，攻擊者會尋找整合的第三方服務，而不是嘗試直接破壞目標 API。

正如您所看到的，雖然存在一些重疊，但應用程式和 API 主要受到不同的、獨特的威脅，組織必須做出相應的回應。 這兩個清單之間的主要區別在於，組織可以使用傳統的多用途安全工具和技術來緩解與應用程式安全相關的所有關鍵風險，但 API 安全性有所不同。

API 安全是一個高度現代化的問題，需要同樣現代的解決方案。 組織不能指望他們用來保護應用程式和其他資產的工具能夠滿足保護 API 的任務。 API安全需要API專用的安全工具； API 閘道和 Web 應用程式防火牆 (WAF) 等傳統保護方法還不夠。