共用方式為

使用 API 管理減輕 OWASP API 安全性前 10 大威脅的建議

  • 發行項

適用於：所有 APIM 層

注意

本文已更新，以反映 2023 年最新的 OWASP API 安全性前 10 名清單。

Open Web Application Security Project (OWASP) Foundation 的作用是透過其社群導向的開放原始碼軟體專案、全球數百篇文章、成千上萬個成員，以及經由主辦當地和全球會議來改善軟體安全性。

OWASP API 安全性專案著重於策略和解決方案，以瞭解並減輕 API 的獨特弱點和安全性風險。 在本文中，我們會討論最新的建議，以使用 Azure API 管理 降低 OWASP 在 2023 年清單中識別的前 10 個 API 威脅。

儘管 API 管理 提供 API 安全性的完整控制，但其他 Microsoft 服務 提供互補功能來偵測或防範 OWASP API 威脅：

損毀的物件層級授權

未受到適當授權層級保護的 API 物件，可能會經由弱式物件存取識別碼而容易遭受資料外洩和未經授權的資料操作。 例如，攻擊者可能會利用可逐一查看的整數物件識別碼。

此威脅的詳細資訊： API1：2023 中斷的物件層級授權

建議

  • 實作物件層級授權的最佳位置是在後端 API 本身內。 在後端，可以使用適用於網域和 API 的邏輯，在要求 (或物件) 層級 (適用的話) 進行正確的授權決策。 根據要求者的權限和授權，考量指定要求者在回應中可能產生不同詳細層級的案例。

  • 如果無法在後端變更目前易受攻擊的 API，則 API 管理可作為後援使用。 例如：

    • 如果未在後端實作，請使用自訂原則來實作物件層級授權。

    • 實作自訂原則，將識別碼從要求對應至後端以及從後端對應至用戶端，讓內部識別碼不會公開。

      在這些情況下，自定義原則可能是 具有查閱原則的原則表達式 （例如字典），或透過 傳送要求 原則與其他服務整合。

  • 針對 GraphQL 案例，使用 authorize 元素透過 validate-graphql-request 原則強制執行物件層級授權。

驗證中斷

網站或 API 的驗證機制特別容易受到攻擊，因為它對匿名用戶開放。 驗證所需的資產和端點，包括忘記的密碼或重設密碼流程，應受到保護，以防止惡意探索。

此威脅的詳細資訊： API2：2023 中斷驗證

建議

中斷的物件屬性層級授權

良好的 API 介面設計具有挑戰性的假象。 通常，特別是隨著一段時間演變的舊版 API，要求和回應介面包含的數據欄位比取用的應用程式所需的更多數據欄位，進而啟用數據插入式攻擊。 攻擊者也可能探索未記載的介面。 這些弱點可能會對攻擊者產生敏感數據。

此威脅的詳細資訊： API3：2023 中斷的物件屬性層級授權

建議

  • 減輕此弱點的最佳方法是確保在後端 API 定義的外部介面經過仔細設計，而且最好與資料持續性無關。 這類介面應該只包含 API 取用者所需的欄位。 API 應該經常檢閱，且舊版欄位已淘汰，而後移除。
  • 在 API 管理 中，使用修訂以正常控制非中斷性變更，例如，將字段新增至介面，以及實作重大變更的版本。 您也應該版本後埠，其生命週期通常與取用者面向 API 不同。
  • 將外部 API 介面與內部數據實作分離。 避免將 API 合約直接繫結至後端服務的資料合約。
  • 如果無法改變後端介面設計和過多資料有所疑慮，請使用 API 管理的轉換原則來重寫回應承載和遮罩或篩選資料。 API 管理 中的內容驗證可以搭配 XML 或 JSON 架構使用，以封鎖具有未記載屬性或不當值的回應。 例如，從回應主體中移除不必要的 JSON 屬性。 封鎖具有未記載屬性的要求可減輕攻擊，而封鎖具有未記載屬性的回應則更加難以將潛在的攻擊媒介進行反向工程。 validate-content 原則也支持封鎖超過指定大小的回應。
  • 使用 validate-status-code 原則來封鎖 API 架構中未定義錯誤的回應。
  • 使用 validate-headers 原則來封鎖未在架構中定義或不符合架構中定義之標頭的回應。 使用 set-header 原則移除不必要的標頭 。
  • 針對 GraphQL 案例，請使用 validate-graphql-request 原則來驗證 GraphQL 要求 、授權特定查詢路徑的存取權，以及限制回應大小。

不受限制的資源耗用量

API 需要執行資源，例如記憶體或CPU，而且可能包含代表作業成本的下游整合（例如，按要求付費服務）。 套用限制有助於保護 API 免於過度耗用資源。

此威脅的詳細資訊： API4：2023 不受限制的資源耗用量

建議

  • 使用 rate-limit-by-key 或 rate-limit 原則，在較短的時間範圍套用節流。 在敏感性端點上套用更嚴格的速率限制原則，例如密碼重設、登入或註冊作業，或耗用大量資源的端點。
  • 使用 配額依據密鑰 或 配額限制 原則來控制允許的 API 呼叫或頻寬數目，以較長的時間範圍。
  • 使用內建快取來最佳化效能，進而減少特定作業的 CPU、記憶體和網路資源耗用量。
  • 套用驗證原則。
  • 針對產生的 AI API：
  • 將後端服務回應所需的時間降到最低。 後端服務回應所需的時間越長，連線在 API 管理 中佔用的時間越長，因此可減少可在指定時間範圍內提供服務的要求數目。
    • 在轉寄要求原則中定義 timeout ，並爭取最短可接受的值。
    • 使用 限制並行 原則限制平行後端連線的數目。
  • 套用 CORS 原則，控制允許透過 API 載入資源的網站。 若要避免過度寬鬆的設定，請勿在 CORS 原則中使用通配符值 （*）。
  • 雖然 Azure 同時具有平臺層級的保護，以及針對分散式阻斷服務 （DDoS） 攻擊的增強保護，但透過在 API 管理 前面部署 Bot 保護服務來改善 API 的應用程式（第 7 層）保護，例如，Azure 應用程式閘道、Azure Front Door 或 Azure DDoS 保護。 搭配 Azure 應用程式閘道 或 Azure Front Door 使用 Web 應用程式防火牆 （WAF） 原則時，請考慮使用 Microsoft_BotManagerRuleSet_1.0。

損毀的功能層級授權

具有不同階層、群組和角色的複雜訪問控制原則，以及系統管理與一般功能之間的不清楚區隔，會導致授權缺陷。 藉由利用這些問題，攻擊者可以存取其他使用者的資源或系統管理功能。

此威脅的詳細資訊： API5：2023 中斷的函式層級授權

建議

  • 根據預設，使用訂用帳戶密鑰或所有 API 層級授權原則來保護 API 管理 中的所有 API 端點。 如果適用，請定義特定 API 或 API 作業的其他授權原則。
  • 使用原則驗證 OAuth 令牌。
    • 使用 validate-azure-ad-token 原則來驗證Microsoft Entra 令牌。 指定所有必要的宣告，如果適用，請指定已授權的應用程式。
    • 若要驗證未由 Microsoft Entra 簽發的令牌，請定義 validate-jwt 原則並強制執行必要的令牌宣告。 可能的話，需要到期時間。
    • 可能的話，請使用加密的令牌或列出特定應用程式進行存取。
    • 監視和檢閱因缺乏授權而拒絕的要求。
  • 使用 Azure 虛擬網路或 Private Link 從網際網路隱藏 API 端點。 深入了解 API 管理的虛擬網路選項。
  • 請勿定義萬用字元 API 作業 (也就是，以 *  作為路徑的 "catch-all" API)。 確保 API 管理只會為明確定義的端點提供要求服務，而對未定義端點的要求會遭到拒絕。
  • 請勿透過不需要訂用帳戶的開放產品發佈 API。
  • 如果已知用戶端 IP，請使用 ip 篩選 原則只允許來自授權 IP 位址的流量。
  • 使用 validate-client-certificate 原則，強制用戶端向 API 管理 實例呈現的憑證符合指定的驗證規則和宣告。

對敏感性商務流程的無限制存取

API 可以將廣泛的功能公開給取用的應用程式。 API 作者必須瞭解 API 所提供的商務流程，以及相關聯的敏感度。 如果公開敏感性流程的 API 未實作適當的保護，企業的風險會更大。

此威脅的詳細資訊： API6：2023 不受限地存取敏感性商務流程

建議

  • 根據客戶端指紋減少或封鎖存取。 例如，使用 傳回響應 原則搭配 選擇 原則，根據User-Agent標頭或其他標頭的一致性，封鎖來自無頭瀏覽器的流量。
  • 使用 validate-parameters 原則 來強制要求標頭符合 API 規格。
  • 使用 ip-filter 原則只允許來自已知IP位址的要求，或拒絕來自特定IP的存取。
  • 使用專用網功能來限制外部對內部 API 的連線。
  • 使用 速率限制索引鍵 原則，根據使用者身分識別、IP 位址或其他值來限制 API 耗用量的尖峰。
  • 使用 Azure 應用程式閘道 或 Azure DDoS Protection 服務來偵測和封鎖 Bot 流量的前 API 管理。

伺服器端要求偽造

當 API 根據 API 呼叫端所傳遞的 URL 值而擷取下游資源時，可能會發生伺服器端要求偽造弱點，而不會進行適當的驗證檢查。

此威脅的詳細資訊： API7：2023 伺服器端要求偽造

建議

  • 可能的話，請勿使用客戶端承載中提供的 URL，例如，作為後端 URL、 傳送要求 原則或 rewrite-url 原則的參數。
  • 如果 API 管理 或後端服務使用商業規則的要求承載中提供的 URL，請定義並強制執行有限清單的主機名、埠、媒體類型，或具有 API 管理 中原則的其他屬性，例如選擇原則和原則表達式。
  • timeout在轉寄要求和傳送要求原則中定義 屬性。
  • 使用驗證原則來驗證和清理要求和響應數據。 如有需要，請使用 set-body 原則來處理回應，並避免傳回原始數據。
  • 使用專用網來限制連線。 例如，如果 API 不需要公用，請限制來自因特網的連線，以減少受攻擊面。

安全性設定錯誤

攻擊者可能會嘗試惡意探索安全性設定錯誤弱點，例如：

  • 遺漏安全性強化
  • 不必要的啟用功能
  • 網路連線不必要地對網際網路開放
  • 使用弱式通訊協定或加密

此威脅的詳細資訊： API8：2023 安全性設定錯誤

建議

  • 正確設定閘道 TLS。 請勿使用易受攻擊的通訊協定 (例如 TLS 1.0、1.1) 或加密。
  • 將 API 設定為只接受加密的流量，例如透過 HTTPS 或 WSS 通訊協定。 您可以使用 Azure 原則 來稽核並強制執行此設定。
  • 請考慮在私人端點後方部署 API 管理，或連結至以內部模式部署的虛擬網路。 在內部網路中，可以從私人網路 (透過防火牆或網路安全性群組) 以及從網際網路 (透過反向 Proxy) 控制存取權。
  • 使用 Azure API 管理 原則：
    • 一律透過 <base> 標籤繼承父代原則。
    • 使用 OAuth 2.0 時，設定及測試 validate-jwt 原則，以在令牌到達後端之前檢查令牌是否存在和有效性。 自動檢查權杖到期時間、權杖簽章和簽發者。 透過原則設定來強制執行宣告、受眾、權杖到期和權杖簽章。 如果您使用 Microsoft Entra，validate-azure-ad-token 原則會提供更全面且更容易的方式來驗證安全性令牌。
    • 設定 CORS 原則，且不要對任何設定選項使用萬用字元 *。 相反地，請明確列出允許的值。
    • 在生產環境中設定 驗證原則 ，以驗證 JSON 和 XML 架構、標頭、查詢參數和狀態代碼，以及強制執行要求或回應的大小上限。
    • 如果API 管理超出網路界限，仍可使用限制呼叫端 IP 原則進行用戶端 IP 驗證。 確保其使用允許清單，而不是封鎖清單。
    • 如果在呼叫端與 API 管理 之間使用用戶端憑證，請使用 validate-client-certificate 原則。 確定 validate-revocation、validate-trust、validate-not-before 和 validate-not-after 屬性都設定為 true。
  • 用戶端憑證 (相互 TLS) 也可以在 API 管理與後端之間套用。 後端應該：
    • 已設定授權認證
    • 在適用的情況下驗證憑證鏈結
    • 在適用的情況下驗證憑證名稱
    • 針對 GraphQL 案例，請使用 validate-graphQL-request 原則。 確定已設定 authorization 元素及 max-size 和 max-depth 屬性。
  • 請勿將秘密儲存在原則檔案或原始檔控制中。 請一律使用 API 管理的具名值，或使用自訂原則運算式在執行階段擷取秘密。 具名值應該與 Azure 金鑰保存庫 整合，或在 API 管理 內將其標示為「秘密」來加密。 絕對不要將秘密儲存在純文字具名值中。
  • 透過需要訂用帳戶的產品發佈 API。 請勿使用不需要訂用帳戶的開放產品。
  • 請確定您的 API 需要訂用帳戶金鑰，即使所有產品都設定為需要訂用帳戶密鑰也一樣。 深入了解
  • 需要所有產品的訂用帳戶核准，並仔細檢閱所有訂用帳戶要求。
  • 使用 金鑰保存庫 整合來管理所有憑證。 這會集中管理憑證，並有助於簡化作業管理工作，例如憑證更新或撤銷。 使用受控識別向金鑰保存庫進行驗證。
  • 使用自我裝載的閘道時，請確定有一個程序可定期將映像更新為最新版本。
  • 將後端服務表示為後端實體。 在適用的情況下，設定授權認證、憑證鏈結驗證和憑證名稱驗證。
  • 可能的話，請使用認證管理員或受控識別來驗證後端服務。
  • 使用 開發人員入口網站時：
    • 如果您選擇自我裝載開發人員入口網站，請確定有一個程序可定期將自我裝載的入口網站更新為最新版本。 預設受控版本的更新是自動的。
    • 使用 Microsoft Entra ID 或 Azure Active Directory B2C 進行使用者註冊和登入。 停用較不安全的預設使用者名稱和密碼驗證。
    • 將使用者群組指派給產品，以控制入口網站中 API 的可見度。
  • 使用 Azure 原則來強制執行 API 管理的資源層級設定和角色型存取控制 (RBAC) 權限以控制資源存取。 將最低必要權限授與給每個使用者。
  • 在開發環境外部使用 DevOps 程序和基礎結構即程式碼方法，確保 API 管理內容和組態變更的一致性，以及將人為錯誤降到最低。
  • 請勿使用任何已淘汰的功能。

不正確的庫存管理

與不當資產管理相關的弱點包括：

  • 缺少適當的 API 文件或擁有權資訊
  • 較舊的 API 版本過多，這可能會遺失安全性修正程式

此威脅的詳細資訊： API9：2023 不正確的清查管理

建議

  • 使用定義完善的 OpenAPI 規格作為匯入 REST API 的來源。 規格允許封裝 API 定義，包括自我記載的中繼資料。
  • 使用 API 介面搭配精確的路徑、資料結構描述、標頭、查詢參數和狀態碼。 避免萬用字元作業。 提供每個 API 和作業的描述，並包含連絡人和授權資訊。
  • 避免未直接參與商務目標的端點。 它們會不必要地增加受攻擊面區域，而使 API 更難以演進。
  • 使用 API 管理 中的修訂和版本來管理 API 變更。 具有強式後端版本控制策略，並認可至支援的 API 版本數目上限 (例如 2 或 3 個舊版)。 規劃快速淘汰，最終移除較舊 (通常較不安全) 的 API 版本。 確定所有可用的 API 版本都實作安全性控制。
  • 使用不同的 API 管理 服務來分隔環境（例如開發、測試和生產環境）。 請確定每個 API 管理 服務都會連線到相同環境中的相依性。 例如，在測試環境中，測試 API 管理資源應該連線到測試 Azure 金鑰保存庫資源和後端服務的測試版本。 使用 DevOps 自動化和基礎結構即程式碼做法，協助維護環境之間的一致性和正確性，並減少人為錯誤。
  • 使用 工作區隔離 API 和相關資源的系統管理許可權。
  • 使用標籤來組織 API 和產品，並將其分組以便發佈。
  • 透過開發人員入口網站發佈 API 以供取用。 請確定 API 檔是最新的。
  • 探索未記載或非受控 API，並透過 API 管理公開它們，以取得更佳的控制。
  • 使用 Azure API 中心來維護完整的 API、版本和部署清查，即使 API 未在 Azure API 管理 中管理也一樣。

不安全的 API 耗用量

透過下游整合取得的資源往往比呼叫端或終端使用者的 API 輸入更受信任。 如果未套用適當的清理和安全性標準，即使透過受信任的服務提供整合，API 也可能很脆弱。

此威脅的詳細資訊： API10：2023 不安全的 API 耗用量

建議

  • 請考慮使用 API 管理 作為後端 API 所整合下游相依性的外觀。
  • 如果下游相依性前面有 API 管理，或下游相依性在 API 管理 中使用傳送要求原則，請使用本檔其他章節的建議，以確保其安全且受控制的耗用量，包括：
    • 確定已啟用安全傳輸，並 強制執行 TLS/SSL 設定
    • 可能的話，請使用認證管理員或受控識別進行驗證
    • 使用 rate-limit-by-key 和 quota-limit-by-key 原則來控制取用
    • 使用 validate-content 和 validate-header 原則來記錄或封鎖不符合 API 規格的回應
    • 使用 set-body 原則轉換回應，例如移除不必要的或敏感性資訊
    • 設定逾時並限制並行

相關內容

深入了解：