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

  • 發行項

適用於：所有 API 管理 層

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

OWASP API 安全性專案著重於策略和解決方案，以瞭解並減輕 API 的獨特弱點和安全性風險。 在本文中，我們將討論使用 Azure API 管理來減輕 OWASP 所識別的前 10 大 API 威脅的建議。

注意

除了遵循本文中的建議之外，您還可以啟用適用於 API 的 Defender (適用於雲端的 Microsoft Defender 的一項功能)，以取得 API 安全性深入解析、建議並進行威脅偵測。 深入了解如何將適用於 API 的 Defender 與 APIM 搭配使用

損毀的物件層級授權

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

此威脅的詳細資訊：API1：2019 損毀的物件層級授權

建議

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

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

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

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

      在這些情況下，自訂原則可能是具有查閱 (例如字典) 的原則運算式，或透過傳送要求原則與其他服務整合。

  • 針對 GraphQL 案例，請使用 authorize 元素，透過驗證 GraphQL 要求原則強制執行物件層級授權。

損毀的使用者驗證

驗證機制通常實作不正確或遺失，而讓攻擊者利用實作缺陷來存取資料。

此威脅的詳細資訊：API2：2019 損毀的使用者驗證

建議

使用 API 管理進行使用者驗證和授權：

  • 驗證 - API 管理支援下列驗證方法：

    • 基本驗證原則 - 使用者名稱和密碼認證。

    • 訂用帳戶金鑰 - 訂用帳戶金鑰提供與基本驗證類似的安全性層級，而且可能不足。 如果訂用帳戶金鑰遭到入侵，攻擊者可能會取得無限制的系統存取權。

    • 用戶端憑證原則 - 使用用戶端憑證比使用基本認證或訂用帳戶金鑰更加安全，但不允許權杖型授權通訊協定所提供的彈性，例如 OAuth 2.0。

  • 授權 - API 管理支援驗證 JWT 原則，可根據從 OAuth 識別提供者的中繼資料端點取得的資訊，檢查傳入 OAuth 2.0 JWT 存取權杖的有效性。 設定原則以檢查相關的權杖宣告、受眾和到期時間。 深入了解如何使用 OAuth 2.0 授權和 Microsoft Entra ID 來保護 API。

其他建議：

  • 使用 API 管理 中的原則來增加安全性。 例如，呼叫速率限制會使用暴力密碼破解攻擊來入侵認證，使不良的執行者變慢。

  • API 應該使用 TLS/SSL (傳輸安全性) 來保護認證或權杖。 認證和權杖應該在要求標頭中傳送，而不是以查詢參數的形式傳送。

  • 在 APIM 的開發人員入口網站中，將 Microsoft Entra ID 或 Azure Active Directory B2C 設定為識別提供者，以提高帳戶安全性。 開發人員入口網站會使用 CAPTCHA 來減輕暴力密碼破解攻擊。

過度資料暴露

良好的 API 介面設計具有挑戰性的假象。 通常，特別是隨著時間演進的舊版 API，要求和回應介面包含的資料欄位比取用應用程式所需的資料欄位還要多。

不良的執行者可能會嘗試直接存取 API (或許藉由重新執行有效的要求)，或嗅探伺服器與 API 之間的流量。 分析 API 動作和可用的資料可能會對攻擊者產生敏感性資料，而分析不會呈現或供前端應用程式使用。

此威脅的詳細資訊：API3：2019 過度資料暴露

建議

  • 減輕此弱點的最佳方法是確保在後端 API 定義的外部介面經過仔細設計，而且最好與資料持續性無關。 這類介面應該只包含 API 取用者所需的欄位。 API 應該經常檢閱，且舊版欄位已淘汰，而後移除。

    在 API 管理中，使用：

    • 修訂用以正常控制非重大變更，例如，將欄位新增至介面。 您可以使用修訂搭配在後端的版本控制實作。

    • 重大變更的版本，例如從介面移除欄位。

  • 如果無法改變後端介面設計和過多資料有所疑慮，請使用 API 管理的轉換原則來重寫回應承載和遮罩或篩選資料。 例如，從回應主體中移除不必要的 JSON 屬性。

  • API 管理中的回應內容驗證可搭配 XML 或 JSON 結構描述使用，以封鎖具有未記載屬性或不正確值的回應。 此原則也支援封鎖超過指定大小的回應。

  • 使用驗證狀態碼原則來封鎖具有 API 結構描述中未定義錯誤的回應。

  • 使用驗證標頭原則來封鎖具有結構描述中未定義或不符合結構描述中定義之標頭的回應。 移除具有 設定標頭原則的不必要標頭。

  • 針對 GraphQL 案例，使用 驗證 GraphQL 要求原則來驗證 GraphQL 要求、授權存取特定查詢路徑，以及限制回應大小。

缺少資源和速率限制

缺少速率限制可能會導致後端服務的資料外洩或成功的 DDoS 攻擊，進而導致所有取用者中斷。

此威脅的詳細資訊：API4：2019 缺少資源和速率限制

建議

  • 使用速率限制 (短期) 和配額限制 (長期) 原則來控制每個取用者允許的 API 呼叫數目或頻寬。

  • 在 OpenAPI 定義中定義嚴格的要求物件定義及其屬性。 例如，針對字串的分頁整數、maxLength 和規則運算式 (RegEx) 定義最大值。 使用驗證內容和 API 管理中的驗證參數原則，強制執行這些結構描述。

  • 使用驗證內容原則來強制執行要求的大小上限。

  • 使用內建快取來最佳化效能，進而減少特定作業的 CPU、記憶體和網路資源耗用量。

  • 強制執行 API 呼叫的驗證 (請參閱損毀的使用者驗證)。 撤銷濫用使用者的存取權。 例如，停用訂用帳戶金鑰、使用限制呼叫端 IP 原則封鎖 IP 位址，或拒絕來自 JWT 權杖的特定使用者宣告要求。

  • 套用 CORS 原則，控制允許透過 API 載入資源的網站。 若要避免過度寬鬆的設定，請勿在 CORS 原則中使用萬用字元值 (*)。

  • 將後端服務回應所需的時間降到最低。 後端服務回應所需的時間越長，API 管理中連線佔用的時間越長，因而減少可在指定的時間範圍內提供服務的要求數目。

  • 雖然 API 管理可以保護後端服務免於遭受 DDoS 攻擊，但可能容易受到這些攻擊本身的攻擊。 在 API 管理的前面部署 Bot 保護服務 (例如，Azure 應用程式閘道、Azure Front Door 或 Azure DDoS 保護)，以更妥善地防禦 DDoS 攻擊。 使用 WAF 搭配 Azure 應用程式閘道或 Azure Front Door 時，請考慮使用 Microsoft_BotManagerRuleSet_1.0。

損毀的功能層級授權

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

此威脅的詳細資訊：API5：2019 損毀的功能層級授權

建議

  • 根據預設，使用訂用帳戶金鑰保護 API 管理中的所有 API 端點。

  • 定義驗證 JWT 原則並強制執行必要的權杖宣告。 如果某些作業需要更嚴格的宣告強制，請只為這些作業定義額外的 validate-jwt 原則。

  • 使用 Azure 虛擬網路或 Private Link 從網際網路隱藏 API 端點。 深入了解 API 管理的虛擬網路選項。

  • 請勿定義萬用字元 API 作業 (也就是，以 * 作為路徑的 "catch-all" API)。 確保 API 管理只會為明確定義的端點提供要求服務，而對未定義端點的要求會遭到拒絕。

  • 請勿透過不需要訂用帳戶的開放產品發佈 API。

大量指派

如果 API 提供的欄位超過指定動作所需的欄位，攻擊者可能會插入過多的屬性，以對資料執行未經授權的作業。 攻擊者可能會檢查要求和回應或其他 API 的格式，或加以猜測，藉此探索未記載的屬性。 如果您未使用強型別的程式設計語言，此弱點特別適用。

此威脅的詳細資訊：API6：2019 大量指派

建議

  • 外部 API 介面應該與內部資料實作分離。 避免將 API 合約直接繫結至後端服務的資料合約。 經常檢閱 API 設計，並使用 API 管理 中的版本設定來淘汰和移除舊版屬性。

  • 精確地定義 API 結構描述中的 XML 和 JSON 合約，並使用驗證內容和驗證參數原則，以封鎖具有未記載屬性的要求和回應。 封鎖具有未記載屬性的要求可減輕攻擊，而封鎖具有未記載屬性的回應則更加難以將潛在的攻擊媒介進行反向工程。

  • 如果無法變更後端介面，請使用轉換原則來重寫要求和回應承載，並將 API 合約與後端合約分離。 例如，遮罩或篩選資料，或移除不需要的 JSON 屬性。

安全性設定錯誤

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

  • 遺漏安全性強化
  • 不必要啟用的功能
  • 網路連線不必要地對網際網路開放
  • 使用弱式通訊協定或加密
  • 可能允許未經授權存取系統的其他設定或端點

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

建議

  • 正確設定閘道 TLS。 請勿使用易受攻擊的通訊協定 (例如 TLS 1.0、1.1) 或加密。

  • 將 API 設定為只接受加密的流量，例如透過 HTTPS 或 WSS 通訊協定。

  • 請考慮在私人端點後方部署 API 管理，或連結至以內部模式部署的虛擬網路。 在內部網路中，可以從私人網路 (透過防火牆或網路安全性群組) 以及從網際網路 (透過反向 Proxy) 控制存取權。

  • 使用 Azure API 管理原則：

    • 一律透過 <base> 標籤繼承父代原則。

    • 使用 OAuth 2.0 時，請在到達後端之前，先設定及測試驗證 JWT 原則以檢查 JWT 權杖的存在性和有效性。 自動檢查權杖到期時間、權杖簽章和簽發者。 透過原則設定來強制執行宣告、受眾、權杖到期和權杖簽章。

    • 設定 CORS 原則，且不要對任何設定選項使用萬用字元 *。 相反地，請明確列出允許的值。

    • 在生產環境中將驗證原則設定為 prevent，以驗證 JSON 和 XML 結構描述、標頭、查詢參數和狀態碼，以及強制執行要求或回應的大小上限。

    • 如果API 管理超出網路界限，仍可使用限制呼叫端 IP 原則進行用戶端 IP 驗證。 確保其使用允許清單，而不是封鎖清單。

    • 如果在呼叫端與 API 管理之間使用用戶端憑證，請使用驗證用戶端憑證原則。 確定 validate-revocation、validate-trust、validate-not-before 和 validate-not-after 屬性都設定為 true。

      • 用戶端憑證 (相互 TLS) 也可以在 API 管理與後端之間套用。 後端應該：

        • 已設定授權認證

        • 在適用的情況下驗證憑證鏈結

        • 在適用的情況下驗證憑證名稱

  • 針對 GraphQL 案例，請使用驗證 GraphQL 要求原則。 確定已設定 authorization 元素及 max-size 和 max-depth 屬性。

  • 請勿將秘密儲存在原則檔案或原始檔控制中。 請一律使用 API 管理的具名值，或使用自訂原則運算式在執行階段擷取秘密。

    • 具名值應該與金鑰保存庫或在 API 管理內加密，方法是將其標示為「秘密」。 絕對不要將秘密儲存在純文字具名值中。

  • 透過需要訂用帳戶的產品發佈 API。 請勿使用不需要訂用帳戶的開放產品。

  • 使用金鑰保存庫整合來管理所有憑證 – 這會集中管理憑證，並可協助簡化作業管理工作，例如憑證更新或撤銷。

  • 使用自我裝載的閘道時，請確定有一個程序可定期將映像更新為最新版本。

  • 將後端服務表示為後端實體。 在適用的情況下，設定授權認證、憑證鏈結驗證和憑證名稱驗證。

  • 使用開發人員入口網站時：

    • 如果您選擇自我裝載開發人員入口網站，請確定有一個程序可定期將自我裝載的入口網站更新為最新版本。 預設受控版本的更新是自動的。

    • 使用 Microsoft Entra ID 或 Azure Active Directory B2C 進行使用者註冊和登入。 停用較不安全的預設使用者名稱和密碼驗證。

    • 將使用者群組指派給產品，以控制入口網站中 API 的可見度。

  • 使用 Azure 原則來強制執行 API 管理的資源層級設定和角色型存取控制 (RBAC) 權限以控制資源存取。 將最低必要權限授與給每個使用者。

  • 在開發環境外部使用 DevOps 程序和基礎結構即程式碼方法，確保 API 管理內容和組態變更的一致性，以及將人為錯誤降到最低。

  • 請勿使用任何已淘汰的功能。

插入

任何接受使用者資料的端點都可能遭受插入式惡意探索。 範例包含但不限於：

  • 命令插入，其中有不良的執行者嘗試改變 API 要求，以在裝載 API 的作業系統上執行命令

  • SQL 插入，其中有不良的執行者嘗試改變 API 要求，以對 API 相依的資料庫執行命令和查詢

此威脅的詳細資訊：API8：2019 插入

建議

  • 新式Web 應用程式防火牆 (WAF) 原則涵蓋許多常見的插入式漏洞。 雖然 API 管理沒有內建 WAF 元件，但強烈建議在 API 管理執行個體 (前面) 部署 WAF 上游。 例如，使用 Azure 應用程式閘道或 Azure Front Door。

    重要

    確保不良的執行者無法略過裝載 WAF 的閘道，並直接連線到 API 管理閘道或後端 API 本身。 可能的緩和措施包括：網路 ACL、使用API 管理原則來依用戶端 IP 限制輸入流量、移除不需要的公用存取，以及用戶端憑證驗證 (也稱為相互 TLS 或 mTLS)。

  • 在適用的情況下，使用結構描述和參數驗證原則，在要求到達後端 API 服務之前，進一步限制和驗證要求。

    API 定義所提供的結構描述應該將 Regex 模式條件約束套用至易受攻擊的欄位。 每個 RegEx 都應該經過測試，才能確保其能充分限制欄位，以減輕常見的插入嘗試。

不正確的資產管理

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

  • 缺少適當的 API 文件或擁有權資訊

  • 較舊的 API 版本過多，這可能會遺失安全性修正程式

此威脅的詳細資訊：API9：2019 不適當的資產管理

建議

  • 使用定義完善的 OpenAPI 規格作為匯入 REST API 的來源。 規格允許封裝 API 定義，包括自我記載的中繼資料。

    • 使用 API 介面搭配精確的路徑、資料結構描述、標頭、查詢參數和狀態碼。 避免萬用字元作業。 提供每個 API 和作業的描述，並包含連絡人和授權資訊。

    • 避免不會直接參與商務目標的端點。 它們會不必要地增加受攻擊面區域，而使 API 更難以演進。

  • 使用 API 管理中的修訂和版本來管理和控制 API 端點。 具有強式後端版本控制策略，並認可至支援的 API 版本數目上限 (例如 2 或 3 個舊版)。 規劃快速淘汰，最終移除較舊 (通常較不安全) 的 API 版本。

  • 使用每個環境的 API 管理環境 (例如開發、測試和生產)。 請確定每個 API 管理執行個體都會連線到其相同環境中的相依性。 例如，在測試環境中，測試 API 管理資源應該連線到測試 Azure 金鑰保存庫資源和後端服務的測試版本。 使用 DevOps 自動化和基礎結構即程式碼做法，協助維護環境之間的一致性和正確性，並減少人為錯誤。

  • 使用標籤來組織 API 和產品，並將其分組以便發佈。

  • 透過內建開發人員入口網站發佈 API 以供取用。 請確定 API 文件是最新的。

  • 探索未記載或非受控 API，並透過 API 管理公開它們，以取得更佳的控制。

記錄和監視不足

記錄和監視不足，加上遺漏或與事件回應的無效整合，可讓攻擊者進一步攻擊系統、維護持續性、重返更多要竄改的系統，以及擷取或終結資料。 大部分的缺口研究都會示範偵測缺口所需的時間超過 200 天，通常是由外部合作對象偵測到，而不是經由內部程序或監視。

此威脅的詳細資訊：API10：2019 記錄和監視不足

建議

下一步

深入了解：