什麼是 API 安全？

API 安全性是 Web 應用程式安全性的核心部分。大多數現代 Web 應用程式都依賴 API 來運作，而 API 允許外部各方存取它，從而給應用程式帶來了額外的風險。就好像一家向公眾開放辦公室的企業：場所內有更多人，其中一些人可能不為企業員工所知，這會帶來更大的風險。同樣，API 允許外部人員使用程式，從而給 API 服務的基礎結構帶來更多風險。

常見的 API 安全風險有哪些？

• 漏洞利用：漏洞利用是指攻擊者向目標傳送特別製作的資料，這些資料利用了目標結構中的缺陷。這些缺陷被稱為「漏洞」，讓攻擊者能夠以各種形式對 API 或其相應的應用程式進行非預期的存取。開放式 Web 應用程式安全性專案 (OWASP) 維護了一個清單，列出了十大 API 漏洞，如 SQL 資料隱碼攻擊、安全性設定錯誤等。如果一個漏洞利用的目標是以前不知道的漏洞，這被稱為 zero-day 威脅——這種威脅非常難以阻止。
• 基於驗證的攻擊：用戶端在發出 API 要求之前需要進行驗證，以便 API 伺服器不會收到來自未知或非法來源的要求。有幾種方法可以做到這一點，但每種方法都可能遭到入侵。例如，攻擊者可以獲取合法用戶端的認證、竊取 API 金鑰或攔截並使用驗證權杖。
• 授權錯誤：授權決定了每個使用者的存取級別。如果不仔細管理授權，API 用戶端可能會存取不應該向其提供的資料，從而增加資料外洩的機會。
• DoS 和 DDoS 攻擊：向一個 API 發出過多的要求，會減慢或停止對其他用戶端的服務。一些攻擊者會故意向 API 發出大量要求，進行阻斷服務 (DoS) 或分散式阻斷服務 (DDoS) 攻擊。

API 安全性策略可以幫助緩解這些和其他風險。

強大的驗證和授權措施有助於確保資料不洩露且只有授權的用戶端才會發出 API 要求。DDoS 防護和限速可以關閉 DDoS 攻擊。結構描述驗證和使用 Web 應用程式防火牆 (WAF) 可以封鎖漏洞利用。

限速和 DDoS 緩解如何協助保護 API？

限速對某人在特定時間範圍內重複一個動作的頻率設定了上限。如果 API 用戶端超過允許的要求數，限速將在一段時間內捨棄或封鎖來自它們的更多要求。

DDoS 緩解有助於阻止 DoS 和 DDoS 攻擊。在 DDoS 攻擊中，攻擊者試圖在短時間內用大量要求淹沒 API。這些要求通常來自多個不同的來源。

限速和 DDoS 緩解對於 API 至關重要，原因如下：

1. 阻止 DoS 和 DDoS 攻擊。透過封鎖或丟棄額外的要求，限速和 DDoS 緩解可防止 API 變得不堪重負。單獨的限速可能無法阻止低速緩慢 DDoS 攻擊，但 DDoS 緩解可以吸收額外的流量。
2. 除了故意攻擊之外，一些用戶端可能只是過度使用 API。這會在運算能力方面消耗 API 服務，且可能會減慢其他用戶端的服務速度。限速有助於防止 API 伺服器過載。

如何封鎖漏洞利用？

要使漏洞利用起作用，惡意 API 要求的結構必須使 API 以其架構師意想不到的方式進行回應。API 開發人員可以透過多種方式封鎖此類惡意要求，其中最重要的兩種方式為：

1. 模式驗證
2. WAF 規則

模式驗證

API 的結構描述指定了 API 的預期行為：它應該獲得的要求類型和它應該提供的回應類型。不符合此結構描述的無效要求可能會導致 API 以意想不到的方式行事，從而可能導致資料洩漏。結構描述驗證可識別無效要求和回應。透過封鎖無效回應，API 開發人員可以避免某些類型的攻擊並協助防止資料洩露。

Web 應用程式防火牆 (WAF) 規則

WAF 的運作方式與傳統的防火牆相似，因為它會封鎖一些網路要求和回應，並允許其他要求和回應通過。它根據一組規則來做這件事：如果一個要求或回應違反了某個規則或符合某個規則，則會被封鎖。WAF 被部署在 API 或 Web 應用程式前面，並監控 HTTP 流量。

可以設定 WAF 規則，封鎖針對某個漏洞的要求和回應模式。WAF 規則還可以封鎖來自某些 IP 位址的要求，這有助於阻止機器人攻擊和其他攻擊者。

為什麼驗證和授權對 API 安全性如此重要？

驗證可確保 API 要求來自合法來源。授權可讓 API 伺服器知道要求的用戶端是否被授權獲取要求的資料。

假設 Alice 構建了一個 API，而 Bob 構建了一個使用 Alice 的 API 的 Web 應用程式。當 Bob 的應用程式向 Alice 的 API 傳送 API 要求時，他會在要求中附加一個標籤，上面寫著「這來自 Bob」。這會驗證 Bob 的要求，以便 Alice 的 API 伺服器知道將該要求視為合法。

Alice 的 API 伺服器還會檢查 Bob 擁有的權限。如果 Bob 的要求是針對 Alice 的 API 已標記為「Bob 可以看到」的資料，則伺服器會滿足該要求。但是，Alice 的 API 可能有一段資料標記為「不給 Bob 看到」，且當 Bob 是要求者時，伺服器不應滿足對該資料的要求。這就是為什麼授權很重要。

（實際上，Bob 會在 API 要求中附加一個金鑰或某種其他形式的驗證，而不僅僅是一個標明「這來自 Bob」的標籤。）

API 有多種驗證方法。最常見的是：

1. API 金鑰

向用戶端分配一個金鑰——即只有它們和 API 服務知道的一個唯一字串。金鑰附加到每個 API 要求。API 伺服器在收到 API 要求時會檢查金鑰，以確保它來自經過驗證的用戶端。

這種驗證方法的缺點是，如果金鑰被盜，攻擊者可以使用它來冒充合法用戶端，然後可以進行各種攻擊。使用 Transport Layer Security (TLS) 等加密通訊協定對 API 的要求和回應進行加密非常重要——這樣，金鑰在通過網際網路時不會以純文字形式公開。

2. 使用者名稱和密碼

API 要求可以使用典型的使用者名稱和密碼認證透過一種稱為 HTTP 驗證的方法進行驗證。在 HTTP 驗證中，使用者名稱和密碼被編碼並新增到所有 API 要求的 HTTP 標頭中。伺服器可以檢查這些認證是否為所允許用戶端的認證，從而對要求進行驗證。

這種方法帶來了通常與密碼相關的所有挑戰：密碼可能會丟失、洩露、被盜、被猜到或與不受信任方分享。密碼也容易受到憑證填充和暴力密碼破解嘗試等的影響。

3. OAuth 權杖

API 伺服器不需要直接從用戶端進行驗證，而是可以使用 OAuth 通訊協定從受信任的驗證伺服器獲取驗證權杖。要使用 API，使用者需要登入第三方服務，而不是直接登入 API。與使用者名稱和密碼方法一樣，這種驗證方法容易受到憑證填充和其他攻擊。

4. 雙向 TLS (mTLS)

TLS 是一種加密通訊協定，它在載入網頁時在用戶端和伺服器之間建立一個加密的、經過驗證的連線。TLS 還可以驗證 API 連線的兩端。

在 mutual TLS (mTLS) 中，用戶端和伺服器都有一個 TLS 憑證。它們使用這些憑證相互驗證，確保兩者都是它們聲稱的身分，而無需依賴密碼或其他驗證方法。

然而，mTLS 的實作可能是一個挑戰：所有 API 端點和用戶端都需要合法的 TLS 憑證，這可能難以執行和維護。

什麼是 API Shield？

Cloudflare API Gateway 從一個儀表板啟用多種 API 安全功能，以防止常見的 API 安全風險。API Gateway 包括：

• 用於 API 端點驗證的 mTLS
• 結構描述驗證，它使用積極的安全模式，只允許符合 API 結構描述的要求
• 資料外洩防護 (DLP)，它掃描傳出 API 的流量，檢查是否存在敏感性資料
• 限速和 DDoS 緩解功能，確保 API 不會過載

進一步瞭解 API Gateway 或 API 安全性解決方案。