OWASP 前 10 大 API 威脅

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

本文說明在 Apigee 中，可採取哪些方法來解決 OWASP 發現的安全漏洞。如需 Apigee 的其他方法，請參閱「Google Cloud 2021 年的 OWASP 前 10 名緩解選項」。

簡介

OWASP 是一個開放式社群，致力於協助機構開發、購買及維護可信賴的應用程式和 API。OWASP 透過 OWASP API Security 專案，發布網頁應用程式和 REST API 最嚴重的安全風險，並提供解決這些風險的建議。

本文將探討如何防範常見的 API 攻擊，這些攻擊是根據 OWASP 2019 年 API 安全威脅前 10 大排行榜所列。最新清單中列出的主要威脅，大多是因驗證和授權控制項位置不當所致，例如在用戶端應用程式中，依賴 API 要求傳回的資料篩選功能，或使用反模式，依賴取用用戶端應用程式來執行存取控制項強制執行作業。

API 生態系統持續快速成長，但令人遺憾的是，API 濫用和誤用導致攻擊者外洩資料，已成為當今最常見的攻擊途徑之一。安全性一直是 Apigee 的首要考量，因此我們推出多項新功能，例如進階 API 作業，其中包含異常偵測功能。不過，正確設計及實作 Apigee 的安全功能，對於降低 API 遭受攻擊的風險至關重要。

由於您無法控管應用程式執行的平台，因此應將消費者應用程式視為不受信任或「公開」。假設任何公開應用程式都可能遭到入侵，因此無法信任這些應用程式來強制執行存取控管 (API1、API5)、篩選回應資料 (API6)，或安全地儲存用戶端密鑰 (API2)，例如 API 金鑰或存取權杖。部分建議是根據 2019 年 OWASP 前 10 大漏洞分析結果提出：

  • 判斷哪些類型的用戶端應用程式會使用您的 API (SPA、行動或瀏覽器型)，並設計適當的驗證、授權和安全性模式。
  • 一律使用「公開用戶端」OAuth 或 OpenID Connect 流程 (強烈建議使用 PKCE)
  • 請先考量應用程式的商業邏輯、定義 OpenAPI 規格，然後設計 API 代理，在 Apigee 中篩選後端的所有回應資料。請勿依賴下游應用程式碼邏輯執行這項操作！
  • 篩選所有含有使用者特定 PII 的資料要求，只允許來自後端的資料屬於要求使用者。

API1:2019 物件層級授權中斷

威脅說明

物件存取要求授權驗證不足，攻擊者可重複使用存取權杖，執行未經授權的動作。授權驗證設定不當，導致出現這項威脅。Apigee 提供 VerifyApiKey、OAuth 和 JSON Web Token (JWT) 政策，有助於防範這項安全漏洞，但請務必正確設定這些政策，以免受到威脅。

為防範這項威脅，應用程式開發和安全團隊必須密切合作。授權本質上是複雜的主題，而要有效進行細部授權，必須深入瞭解應用程式的商業邏輯。

從 Apigee 實作角度來看，有兩個主要層面需要考量：

  • 存取權杖完整性
  • 強制執行存取控管

存取權杖完整性

請務必使用正確的 OAuth 或 OpenID Connect 流程，搭配適當的憑證驗證或簽署機制，驗證要求用戶端提供的權杖是否遭到竄改。Apigee 支援所有常用的 OAuth 流程。

Apigee 存取權杖驗證政策包括：

強制執行存取控管

驗證存取權杖的有效性後，請務必實作存取控管強制執行政策，根據授權權杖的存取權利評估每項傳入的 API 要求。

Apigee 提供兩種主要機制，用於驗證及強制執行授權政策：

  • 內部：使用條件式流程，根據從授權權杖擷取為流程變數的聲明，評估存取要求
  • 委派：使用服務 註解呼叫第三方存取權管理解決方案

如果存取控管模型相對簡單，建議採用內部方法 (如上圖所示)。舉例來說，如果從存取權杖擷取的聲明可用於直接評估及授權 API 物件要求。

使用 OAuth 或 JWT 政策適用的流程變數，透過條件式流程陳述式評估存取要求。

如果從存取權權杖擷取的聲明無法直接用於授權對後端物件的 API 要求，或是需要另外呼叫授權伺服器才能取得存取權權杖的複雜 OAuth 流程類型，建議採用「委派」方法 (如上圖所示)。

使用服務註解政策，您可以向第三方服務要求授權政策裁決，或取得要求代理程式的其他權杖附加資訊，然後使用條件式流程做出存取控管決策。

API2:2019 損毀的使用者驗證

威脅說明

如果使用者驗證政策實作不當，攻擊者就能利用驗證實作中的缺陷，冒充合法使用者。實作驗證方法時，請注意以下驗證原則：

  • 請務必驗證使用者代理程式 (應用程式) 和提出要求的使用者
  • 使用委派驗證和授權模式，避免在 API 要求中直接傳遞密碼
  • 請務必驗證存取憑證的簽章，並確保使用的所有存取憑證都已定義到期時間
  • 設定配額，並使用 Apigee Sense 偵測及因應機器人驅動的蠻力攻擊，防範這類攻擊

在由外而內的範例中，API 設計是根據資料使用者的用途而建構，而非後端系統中現有資料的結構，且為外部使用者設計 API 時，安全性是重要元素。傳統後端系統並非為了暴露於公開網路而建構，因此驗證實作項目不夠強大。此時，Apigee 搭配身分與存取權管理解決方案，就能提供強大的解決方案，防範這類威脅。

這裡有幾個主要元素需要考量，我們會在後續章節中說明：

  • 安全設計：充分運用 Apigee 功能，實作驗證模式
  • 管理：確保所有已發布的 API 產品都一致採用設計的驗證模式
  • 作業安全：能夠偵測可疑或異常行為，以及規避或暴力破解驗證 API Proxy 的嘗試

安全設計

安全設計的目標是正確實作驗證流程，並與第三方身分工具整合。安全設計是重要階段，首先要根據會使用 API 端點的應用程式類型，瞭解要使用哪種委派驗證流程。下一步是與身分團隊一起定義要透過身分解決方案實作的整合模式。

OpenID Connect 和 OAuth RFC 提供多種委派驗證和授權流程，以及這些流程涉及的參與者。這是一個複雜的主題，因此驗證機制失效成為 OWASP API 威脅前幾名，也就不足為奇。本文件無法提供身分識別標準的正確導入方式，但 Apigee 提供許多額外資源，協助您進一步瞭解 OAuth 流程，例如這本電子書、網路廣播和範例導入方式。

驗證政策

Apigee 政策可協助解決身分識別和驗證問題，包括：

流量管理

下列 Apigee 流量管理功能有助於防範暴力攻擊：

  • SpikeArrest 政策，用於設定 API Proxy 的整體滾動平均頻率限制
  • 配額政策：根據應用程式金鑰、開發人員或 API 產品配額定義的配額，為 API Proxy 設定精細的速率限制
  • 快取政策，可根據定義的到期時間快取儲存的存取權杖，以及使快取憑證失效 (例如在有效存取權杖遭盜用的情況下)

管理

安全防護是持續進行的程序，而非「設定後就忘記」的專案，而設定錯誤是導致安全漏洞的主因之一。定義驗證流程、身分整合模式和驗證相關流量管理政策後，請務必正確且一致地實作這些項目。

Apigee 提供多項功能和工具，可確保實作完整性，並防止設定錯誤。

角色式存取控管 (RBAC)

無論是大型企業還是小型新創公司，只要確保只有適當的人員和團隊可以存取及修改 API 代理設定，就能避免設定錯誤。API 計畫由貴機構的跨領域團隊支援。在 API 歷程中，請務必只授予每個團隊執行工作所需的權限。

Apigee 提供多項功能，讓您管理角色型存取權，您可以將使用者指派給預先定義的角色，也可以建立自訂角色，滿足 API 團隊的需求。正確定義及管理角色指派作業，是安全擴展 API 計畫的關鍵。您也可以使用同盟與現有的公司目錄整合，減少在 Apigee 中管理第二組管理員憑證的需求。

共用流程

共用流程可讓您將政策和資源定義為可重複使用的物件，並在 API Proxy 中實作。舉例來說，您可能與安全團隊合作，根據使用 API 的應用程式類型，設計多種驗證設計模式。API 開發人員不必是身分識別專家，也能重複使用這個流程，只要知道要新增至現有 API 代理設定的正確共用流程，並使用 Flow 呼叫政策即可。

圖：共用流程是可重複使用的政策和條件式邏輯組合，可讓您維護複合模式。

作業安全性

API 採用適當的驗證模式，並在正式環境中執行，且已完成基本流量管理後，SecOps 團隊也必須能夠監控可疑活動並做出回應，這類活動通常會從嘗試盜用驗證憑證開始。

Apigee Sense

Apigee Sense 可保護 API 免受惡意用戶端攻擊等不當要求流量侵擾。Apigee Sense 會分析 API 要求流量，找出可能代表非預期要求的模式。透過這項分析，您可以找出發出不當要求的用戶端，然後採取行動允許、封鎖或標記這些要求。Sense 未來將提供自動對可疑流量啟用 reCAPTCHA 驗證的功能。

Apigee Sense 可保護 API，防範包含下列內容的要求模式：

  • 自動化行為與人類行為混合
  • 來自相同 IP 的持續嘗試
  • 異常錯誤率
  • 可疑的用戶端要求
  • 資料檢索
  • 金鑰收集和驗證蠻力攻擊
  • 活動爆發
  • 地理模式

Advanced API Ops

Sense 專門用於偵測及回應類似機器人的威脅，而 Advanced API Ops 則包含異常偵測和進階快訊定義。

異常偵測功能會將人工智慧 (AI) 和機器學習 (ML) 模型套用至歷來 API 資料，異常偵測功能隨後會針對您未曾想過的情況，即時發出快訊，有助於提高生產力，並縮短 API 問題的平均解決時間 (MTTR)。

Advanced API Ops 以現有的 API 監控快訊機制為基礎，新增下列進階快訊類型：

  • 異常快訊。Edge 會偵測流量和效能問題，您不必自行預先判斷。然後針對這些異常狀況發出快訊
  • TLS 到期警報。在 TLS 憑證即將到期時發出通知

API3:2019 資料暴露過多

威脅說明

發布的 API 可能會公開過多資料，需要由用戶端應用程式執行必要的篩選作業。如果攻擊者直接查詢基礎 API，就能存取機密資料。

Apigee 的 API 設計「由外而內」設計原則之一是「資料簡潔」。與 UX 設計師和開發人員合作，只透過 API 公開應用程式 UI 中需要的資料。後端系統並非為公開使用模式而建構，因此使用 Apigee 進行 API 優先設計時，首要工作之一就是盡量減少公開資料，為客戶和開發人員提供優質的 API 產品。

Apigee 的另一項設計原則是「可重複使用」。除了安全性考量外，如果依賴應用程式篩選 API 提供的資料，您就必須為開發應用程式的每個平台移植篩選邏輯。

從安全性的角度來看，這種威脅是將授權強制執行作業委派給應用程式所致，但通常是在您無法控管的平台或作業系統上。我們已在 API1 和 API2 中探討正確導入驗證和授權的重要性，以避免未經授權存取資料。

接下來的章節將探討如何：

  • 重新編寫對後端服務的要求和回應，盡量減少資料曝光
  • 實作錯誤處理機制，防止詳細的錯誤訊息向攻擊者揭露後端服務的機密環境資訊

重新編寫回覆和要求

後端系統通常不適合在公開應用程式或不受信任的公開網路中使用。Apigee Edge 的設計宗旨是協助您部署公用 API 產品，同時避免後端過度資料暴露。

為此，Apigee 會使用三項重要政策：

  • 指派訊息
  • 程式碼註解
  • 錯誤處理

指派訊息政策

Assign Message 政策會在 API Proxy 流程中變更或建立新的要求和回應訊息。這項政策可讓您對這些郵件執行下列動作：

  • 新增 訊息的表單參數、標頭或查詢參數
  • 複製 現有屬性，從一則訊息複製到另一則
  • 移除 訊息中的標頭、查詢參數、表單參數和/或訊息酬載
  • 設定訊息中現有屬性的值

使用「指派訊息」時，通常會新增、變更或移除要求或回應的屬性。不過，您也可以使用 Assign Message 建立自訂要求或回應訊息，並將其傳遞至替代目標，詳情請參閱「建立自訂要求訊息」。

使用自訂程式碼進行複雜的重寫作業

如果資料處理和重寫規則很複雜，超出指派郵件政策的功能範圍，可以使用程序語言，例如 JavaScript、Java 或 Python。您可以將自訂程式碼新增至 API Proxy，然後從新增至 Proxy 流程的政策中呼叫該程式碼。 程序碼支援功能可協助您更輕鬆地實作流程變數、錯誤，以及要求和回應主體的複雜處理作業。

使用程序碼，您可以：

  • 建立或操控複雜的主體值，例如要求和回應值。
  • 重寫網址，例如遮蓋目標端點網址。

Apigee Edge 針對支援的語言提供個別政策：JavaScript 政策、Java Callout 政策和 Python Script 政策。

錯誤處理

Apigee 可讓您使用 Raise Fault 類型的政策，執行自訂例外狀況處理作業。Raise Fault 政策是 Assign Message 政策的變體，可讓您產生自訂錯誤回應，以回應錯誤情況。

共用流程

共用流程可用來強制執行錯誤訊息的標準化。舉例來說，如果設定的政策可偵測後端傳回的特定 HTTP 錯誤代碼，就能用來重新編寫錯誤回應，傳回一般錯誤訊息。

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

威脅說明

如果未實作速率限制政策，攻擊者可能會發動阻斷服務攻擊，導致後端不堪負荷。

使用下列 Apigee 功能，即可輕鬆解決這項威脅：

  • 配額和尖峰流量防範政策：做為預防性控管措施，對傳入的 API 要求設下流量限制
  • Apigee Sense 可動態偵測及因應機器人驅動的攻擊
  • 進階 API 監控和警報，做為偵測性控制措施，以便在發生 DDoS 攻擊時收到警報

使用配額和 SpikeArrest 政策設定頻率限制

Apigee 提供兩種頻率限制政策：

  • 尖峰流量防護提供一般政策，可在 API Proxy 層級定義，用於限制傳入後端的要求總數，
  • 配額是精細的政策工具，可強制執行 API Proxy 或 API 產品層級的配額政策。

Spike Arrest

「SpikeArrest」 政策可防範流量暴增。這項政策會限制 API Proxy 處理並傳送至後端的要求數量，以防止效能延遲和停機，並使用政策中可定義的累計平均值。

配額

Quota政策可讓您設定 API Proxy 在一段時間內 (例如每分鐘、每小時、每天、每週或每月) 允許的要求訊息數。您可以為所有存取 API Proxy 的應用程式設定相同配額，也可以根據下列條件設定配額：

  • 包含 API Proxy 的產品
  • 要求 API 的應用程式
  • 應用程式開發人員
  • 其他許多條件

這項政策比尖峰抑制更精細，一般應與尖峰抑制政策一併使用。

使用 Apigee Sense 偵測機器人

使用 Apigee Sense，您可以根據特定用戶端或位置顯示的惡意或可疑行為，採取行動明確允許、封鎖或標記特定用戶端、IP 範圍或自治系統機構的要求。Apigee Edge 會先對要求套用這些動作，再由 API Proxy 處理要求。舉例來說，系統可以偵測到出現「暴力猜測者」行為的 IP 範圍或特定用戶端，然後封鎖或標記這些項目。

透過 Advanced API Ops Monitoring 偵測威脅

使用流量快訊，在環境、Proxy 或區域的流量在一段時間內變更指定百分比時，發出通知。如果流量大幅偏離預期輸送量 (例如發生 DDoS 攻擊時)，這項功能就會動態發出警報。這些快訊可以輕鬆傳送至第三方記錄和監控解決方案。

API5:2019 功能層級授權中斷

威脅說明

這項威脅是 API1 的變種，也是授權安全漏洞。攻擊者可以透過這項威脅，將要求傳送至未經授權存取的函式，進而執行動作。舉例來說，如果 API 端點未驗證 HTTP 要求動詞，攻擊者可能會將 GET 替換為 PUT 或 DELETE，藉此修改或刪除他們僅有權讀取的資料。或者，如果未在 API 資源 URI 路徑上實作足夠嚴格的存取控管，API 端點可能會允許攻擊者只要變更要求中的路徑，就能查看其他使用者的資料。

這類威脅凸顯了使用 Apigee 做為中介和抽象層的價值，因為許多後端系統並非專為公開存取而設計，預設可能會提供單一端點來執行多個商業邏輯函式，包括高風險的管理功能。

為降低這類威脅的可能性，概念元素通常會細分為：

  • What is being protected? 思考 API 產品策略，並使用 RESTful 最佳做法設計 Apigee API 代理項目、產品和應用程式功能公開的路徑和資源時，實作功能邏輯區隔。
  • 誰有權存取您的 API 資源？定義高層級角色，並使用 Apigee 的部分驗證和授權功能，實作「最低權限」預設存取權利，如 API1 和 API2 所述。
  • 如何執行存取權政策？使用條件式流程和錯誤，驗證所有 API 要求的網址路徑和動詞。

圖：這張圖表說明 Apigee 如何使用存取權杖中提供的範圍做為權利，強制執行函式層級授權。

使用 API Proxy、產品和應用程式進行邏輯區隔

Apigee 提供高度彈性的工具包，可讓您對 API 資源進行邏輯區隔，將API Proxy 整合至任意數量的 API 產品，供應用程式開發人員使用，並註冊應用程式來使用 API 產品。您可以在上述任一層級定義存取政策。

如要實作有效的功能授權和區隔，定義 API 產品策略至關重要。這個持續進行的重要程序包括從客戶和開發人員的角度，定義 API 產品的「對象」和「內容」，然後在路徑資源和 HTTP 動詞層級定義允許的要求類型。

圖：封裝至 API 產品的 API 資源可來自一或多個 API，因此您可以混合搭配資源，建立用量層級和授權界線。

透過 OAuth 範圍和 JWT 聲明控管函式層級的存取權

雖然上述針對 API1:2019 物件授權中斷考量的授權方法，可解決物件層級的精細存取控管問題，但解決函式層級的粗略存取控管問題也同樣重要。要求存取的使用者是否獲准要求存取這個網址路徑？這類政策通常會根據使用者角色 (客戶、員工、管理員、內部或第三方開發人員) 定義。

為降低設定錯誤的風險，建議您與安全團隊合作，確保存取權杖中包含有關要求使用者的聲明，方法是使用 OAuth 範圍或 JWT 聲明。

使用條件式流程要求驗證

從基礎層面來看，REST API 呼叫包含下列項目：

  • 端點
  • 資源
  • 動作動詞
  • 任意數量的其他要求屬性，例如查詢參數

這類攻擊通常是因為 API 要求篩選不足所致，因此攻擊者可以執行未經授權的操作，或存取受保護的資源。除了可根據存取權杖或聲明篩選要求的條件式邏輯，Apigee 也允許根據要求本身實作篩選邏輯。

清楚瞭解並定義 API 產品的業務邏輯，以及 API 允許的功能後，下一步就是透過下列 Apigee 產品功能，限制超出範圍的要求：

  • 條件式邏輯和 Raise Fault 政策，可在 Proxy 流程設定的任何步驟中限制資源路徑或動詞
  • JSON 和 XML 威脅防護政策，可防範使用格式錯誤的 JSON 或 XML 要求酬載發動的內容型攻擊

API6:2019 大量指派

威脅說明

透過 API 提供給用戶端應用程式的未經過濾資料，可能會讓攻擊者透過要求猜測物件屬性，或使用端點命名慣例，找出在後端儲存的資料物件上執行未授權修改或存取屬性的位置。

如果未經過濾的資料 (通常為 JSON 或 XML) 傳送至用戶端，攻擊者就能猜測後端系統的基礎實作詳細資料，以及機密資料元素的屬性名稱，進而造成這項威脅。這類攻擊的結果可能導致攻擊者讀取或操縱不當資料，最糟的情況下，還可能導致遠端執行程式碼漏洞。

允許這類威脅通常涉及以下兩方面：

  • API 設計觀點。請勿依賴應用程式邏輯執行用戶端資料篩選，因為攻擊者可能會利用應用程式，並將其視為可信任的來源。設計 API 資料結構時，請務必只公開必要的最低資料量，以啟用 API 服務
  • API 實作觀點。實作資料篩選和結構定義驗證，防止機密資料意外暴露給用戶端應用程式

從 Apigee 產品的角度來看，我們提供多項實用功能，確保 API 實作的資料篩選機制穩健可靠。

OpenAPI 規格篩選政策

OASValidation (OpenAPI 規格驗證) 政策可讓您根據 OpenAPI 3.0 規格 (JSON 或 YAML) 驗證傳入的要求或回應訊息。這項政策可讓您：

  1. 建立 OpenAPI 規格 (OAS) 來設計 API
  2. 實作必要的調解、安全性和快取邏輯，透過 Apigee 安全地公開後端的 API 產品
  3. 根據 OAS 規格中定義的資料結構定義，驗證傳入的要求，包括基本路徑、動詞、要求訊息政策和參數

SOAP 訊息驗證政策

SOAP 訊息驗證政策可讓您驗證 XML 型要求，方法是根據 XSD 架構驗證 XML 訊息，或是根據 WSDL 定義驗證 SOAP 訊息。此外，您可以使用「訊息驗證」政策，確認 JSON 或 XML 訊息酬載格式正確，包括驗證 XML 或 JSON 訊息中的下列項目：

  • 只有一個根元素
  • 內容中沒有無效字元
  • 物件和標記正確巢狀結構
  • 開始和結束標記相符

API7:2019 安全性設定錯誤

威脅說明

安全性設定錯誤通常是因為預設設定不安全、設定不完整或臨時設定、開放式雲端儲存空間、設定錯誤的 HTTP 標頭、不必要的 HTTP 方法、寬鬆的跨來源資源共用 (CORS)，以及包含機密資訊的詳細錯誤訊息。攻擊者通常會嘗試找出未修補的瑕疵、常見端點，或未受保護的檔案和目錄，藉此取得未經授權的存取權，或瞭解他們想攻擊的系統。安全性設定錯誤不僅會洩漏敏感的使用者資料，還可能導致系統詳細資料外洩，進而造成伺服器全面遭駭。此外，安全設定錯誤的漏洞可能還有其他用途，包括：

  • TLS 設定錯誤
  • 含有堆疊追蹤的錯誤訊息
  • 未修補的系統
  • 公開儲存空間或伺服器管理面板

機構可以採取各種步驟，解決並減輕安全設定錯誤帶來的挑戰，包括：

  1. 建立並標準化強化和修補程序
  2. 為 API 生態系統制定管理機制
  3. 限制管理員存取權，並啟用稽核和快訊功能

共用流程和流程掛鉤

Apigee 支援共用流程的概念，可讓 API 開發人員將政策和資源組合成可重複使用的群組。共用流程可將可重複使用的功能集中在一處，有助於確保一致性、縮短開發時間，以及更輕鬆地管理程式碼。您可以在個別 API Proxy 中加入共用流程，也可以進一步將共用流程放在流程掛鉤中，以便為部署在與共用流程相同環境中的每個 API Proxy，自動執行共用流程邏輯。

API Monitoring

Apigee 提供完整的 API 監控平台。機構可透過 API 監控功能，主動偵測 API 流量和效能問題。Apigee API Monitoring 可與 Apigee Edge for Public Cloud 搭配使用，即時提供 API 效能的脈絡洞察資訊，協助快速診斷問題，並採取補救措施，確保業務持續運作。

圖：Apigee API Monitoring 提供各種工具，可監控、調查及處理問題。並運用 Google Cloud Platform 的頂尖智慧功能。

Apigee Sense

Apigee Sense 可協助保護 API 免於不當要求流量的侵擾，包括惡意用戶端的攻擊。Apigee Sense 會分析 API 要求流量，找出可能代表非預期要求的模式。

組織可根據這項分析找出發出不當要求的用戶端，然後採取行動，允許、封鎖或標記這些要求。Apigee Sense 可保護 API 免受下列要求模式影響：

  • 自動化行為與人類行為混合
  • 來自相同 IP 的持續嘗試
  • 異常錯誤率
  • 可疑的用戶端要求
  • 資料檢索
  • 金鑰收集
  • 活動爆發
  • 地理模式

API8:2019 注入

威脅說明

如果將不受信任的資料 (例如 SQL、NoSQL、XML 剖析器、ORM、LDAP、OS 指令和 JavaScript) 注入 API 要求，可能會導致系統執行非預期的指令或未經授權存取資料。攻擊者會透過任何可用的注入向量 (例如直接輸入、參數、整合服務等)，將惡意資料提供給 API，並預期這些資料會傳送至解譯器。攻擊者使用安全漏洞掃描工具和模糊測試器檢查原始碼時，可以輕易發現這些瑕疵。成功注入後，可能會導致資訊揭露，影響機密性及資料遺失，在某些情況下也可能導致 DoS。

為減輕注入錯誤/攻擊，最佳做法包括嚴格定義輸入資料 (例如結構定義、類型、字串模式)、執行輸入驗證、限制檢查，以及在執行階段強制執行這些做法。Apigee 平台可使用篩選器驗證傳入資料，只允許每個輸入參數使用有效值。

Apigee Edge 會做為傳入 API 要求的伺服器，檢查酬載結構是否在可接受的範圍內，這也稱為限制檢查。您可以設定 API Proxy，讓輸入驗證常式轉換輸入內容，移除有風險的字元序列，並以安全值取代。

規則運算式保護政策

RegularExpressionProtection 政策會從訊息中擷取資訊 (例如 URI 路徑、查詢參數、標頭、表單參數、變數、XML 酬載或 JSON 酬載)，並根據預先定義的規則運算式評估該內容。如果任何指定的規則運算式評估結果為 true，系統就會將郵件視為威脅並拒絕。規則運算式 (簡稱 regex) 是一組字串，可指定字串中的模式。規則運算式可讓系統以程式輔助方式評估內容模式。舉例來說，您可以使用規則運算式評估電子郵件地址，確保結構正確。

RegularExpressionProtection 最常見的用途是評估 JSON 和 XML 酬載是否含有惡意內容。

沒有任何規則運算式可以完全杜絕內容型攻擊，因此應結合多種機制，才能實現縱深防禦。本節說明幾種建議的模式，可防止使用者存取內容。

Apigee 平台提供多種其他方法來驗證輸入內容：

驗證內容類型

內容類型是指透過 HTTP 傳輸的檔案內容，並根據兩部分結構進行分類。Apigee 建議使用條件式邏輯驗證要求和回應的內容類型，詳情請參閱下文。

API9:2019 資產管理不當

威脅說明

環境管理和環境隔離措施不足，導致攻擊者可存取安全性不足的 API 端點。缺乏管理防護措施也會導致已淘汰的資源不必要地曝光。

您可以運用 Apigee 成熟的功能管理完整 API 生命週期，建立全方位的管理模式，讓團隊協作，同時在安全利益關係人和 API 開發人員之間劃分責任，解決這項威脅。您可以使用下列工具設定及維護邊界和控制項：

機構、環境和修訂版本：虛擬和實體防護機制，可透過執行階段環境確保隔離，並提供安全的升級程序。

角色型存取控制：只有 API 團隊中必要的人員，才能管理設定變更和升級程序。

API 說明文件的目標對象管理：在開發人員入口網站中發布 API 後，您可以管理目標對象，限制說明文件的瀏覽權限。

流程掛鉤：您可以強制執行全域政策和模式，並將其管理為 API 開發人員無法修改的專屬防護措施。

機構和環境

Apigee 中的設定構件、使用者和功能可以限定在特定機構和/或環境。也就是說，平台已預先建構防護措施，可圍繞 API 及其支援的設定。

機構：機構是 Apigee 中的頂層租戶。您可以完全區隔流量、設定和使用者。根據治理最佳做法，您應考慮建立獨立的正式和非正式機構。這項做法可有效避免將生產資料、使用者和流量與較低的環境混用。

環境： Apigee 中的 API 可以透過多個部署狀態升級，每個狀態都會連結至執行環境。升級程序不會一併帶入環境內容， 因此可避免向沒有權限的使用者公開敏感設定。

修訂版本： 修訂版本可讓 API 和個別功能在環境中順暢升級。

角色式存取控管

為減輕 API9 的影響，請務必清楚定義安全利益關係人和 API 開發人員的職責，並加以區分。如本文先前所述，Apigee 具有彈性的角色型存取權控管功能，可讓您將權限指派給自訂角色。針對這項特定威脅，角色可限定範圍，只具備每個機構、環境或更精細設定權限的有限權限。建議您限制透過環境變更 API 部署狀態的權限，並確保開發人員無法存取或修改全域安全程式庫 (流程掛鉤)。這些受限角色可防止對全域安全政策進行未經授權的變更，這類政策涵蓋舊版和目前發布的端點。

目標對象管理 API 說明文件

開發人員入口網站是 API 策略能否成功的關鍵元件，可讓您全面掌握所有 API 相關說明文件，包括主機/端點、資源、作業、酬載結構定義等。在 Apigee 中，您可以使用 API 產品建構函式將 API 分組。API 產品是由資源和作業組合定義，這些資源和作業屬於相同的業務和安全環境 (例如服務方案、業務領域、類別、公司階層等)。

透過 Apigee 的整合式開發人員入口網站，您可以發布 API 產品，並管理目標對象，限制發布內容的瀏覽權限。這項功能符合內容區隔策略，可滿足業務和安全防護需求。

流程掛鉤

API 的宣傳和發布程序一律須包含安全法規遵循和認證程序。為確保有效性，API 團隊應使用適當工具建立防護措施，確保責任劃分明確，同時維持敏捷的發布週期。

您可以透過 Flow Hooks 強制執行全域政策，提升安全控管職責。這些全域政策可做為受保護的防護措施進行管理，API 開發人員無法修改，因此可確保責任劃分，並透過套用預設安全性來提升敏捷度，進而為特定執行環境中部署的所有 API 提供安全性合規性。

圖：您可以在 Apigee 中透過流程掛鉤和共用流程，設定具備權限的防護措施。 安全利害關係人負責維護與安全相關的全球政策。這些功能可確保責任劃分明確，並促進敏捷開發生命週期。

API10:2019 記錄與監控不足

威脅說明

記錄、監控和快訊不足會導致進行中的攻擊未遭偵測，因此您應制定策略，取得對業務有影響的重大事件洞察資料。

API 的事件和記錄管理策略應考量下列最佳做法：

  • 記錄管理政策：記錄並強制執行規則，以標準化及控管記錄詳細程度、記錄層級、記錄完整性、集中式存放區等
  • 活動管理政策：確保每個活動都能追溯至來源。此外，事件應可依重要性和業務影響分類。
  • 報告和稽核：安全性和營運相關人員應能即時存取記錄和事件，並採取因應措施。此外，利害關係人可以執行強化週期，根據歷來資料調整偵測模式，

Apigee 提供必要工具，協助您制定完善的事件和記錄管理策略。這些工具包括：

訊息記錄政策：根據 API 流量的流量資料或中繼資料建立記錄串流。您可以運用條件式邏輯和訊息範本，彈性決定串流詳細程度。

Google Cloud 作業套件：善用現成整合功能，將 Google 的監控和記錄工具擴充至極大規模。

服務 標註政策：新增對需要 HTTP 端點傳送事件的記錄串流支援。

Analytics： 透過預設和/或自訂報表存取及分析歷來流量中繼資料。 根據趨勢建立及管理快訊，並瞭解流量異常狀況。

API Monitoring：如先前所述，這項工具提供警告功能，可根據重大事件觸發警告。您可以進一步分析流量記錄，並採取相應行動。