使用 API 管理缓解 OWASP API 安全性十大威胁的建议

Open Web Application Security Project (OWASP) 基金会通过由社区主导的开放源代码软件项目、全球数百个分会、数万名会员，以及通过举办地方和全球会议，致力于提高软件安全性。

OWASP API 安全项目的重点是制定策略和解决方案来了解并缓解 API 的特有漏洞和安全风险。 在本文中，我们将讨论使用 Azure API 管理来缓解 OWASP 标识的十大 API 威胁的建议。

对象级别授权中断

对于未使用适当级别的授权保护的 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（传输安全性）来保护凭据或令牌。 凭据和令牌应在请求头中发送，而不是作为查询参数发送。

• 在 API 管理的开发人员门户中，将 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 管理中占用的连接时间就越长，从而减少了可在给定时间范围内提供的请求数。

  • 在转发请求策略中定义 timeout。

  • 对 GraphQL API 使用验证 GraphQL 请求策略并配置 max-depth 和 max-size 参数。

  • 使用限制并发策略限制并行后端连接数。

• 虽然 API 管理可以保护后端服务免受 DDoS 攻击，但它可能容易受到这些攻击本身的影响。 在 API 管理前面部署机器人防护服务（例如，Azure 应用程序网关），以更好地防范 DDoS 攻击。

功能级别授权中断

具有不同层次结构、组和角色的复杂访问控制策略，以及管理功能和常规功能之间不明确的分离，都会导致授权缺陷。 通过利用这些问题，攻击者可以访问其他用户的资源或管理功能。

有关此威胁的详细信息，请参阅：API5:2019 功能级别授权中断

建议

• 默认情况下，使用订阅密钥保护 API 管理中的所有 API 终结点。

• 定义验证 JWT 策略并强制实施所需的令牌声明。 如果某些操作需要更严格的声明实施，请仅为这些操作定义额外的 validate-jwt 策略。

• 使用 Azure 虚拟网络或专用链接对 Internet 隐藏 API 终结点。 详细了解 API 管理的虚拟网络选项。

• 请勿定义通配符 API 操作（即以 * 为路径的“全能”API）。 确保 API 管理仅为显式定义的终结点请求提供服务，而对未定义的终结点的请求则被拒绝。

• 不要通过不需要订阅的开放产品发布 API。

大量分配

如果一个 API 提供的字段超过了客户端对给定操作的需求，攻击者可能会注入过多的属性来对数据执行未经授权的操作。 攻击者可以通过检查请求和响应或其他 API 的格式来发现未记录的属性，或进行猜测。 如果你不使用强类型的编程语言，则此漏洞尤其适用。

有关此威胁的详细信息，请参阅：API6:2019 大量分配

建议

• 外部 API 接口应与内部数据实现分离。 避免将 API 协定直接绑定到后端服务中的数据协定。 经常检查 API 设计，并在 API 管理中使用版本控制来弃用和删除旧属性。

• 在 API 架构中精确定义 XML 和 JSON 协定，并使用验证内容和验证参数策略来阻止包含未记录属性的请求和响应。 阻止包含未记录属性的请求可以缓解攻击，而阻止包含未记录属性的响应使得潜在攻击途径的反向工程更加困难。

• 如果无法更改后端接口，可以使用转换策略来重写请求和响应有效负载，并将 API 协定与后端协定分开。 例如，屏蔽或筛选数据，或删除不需要的 JSON 属性。

安全配置错误

攻击者可能会试图利用安全配置错误漏洞，例如：

• 缺少安全强化措施
• 启用了不必要的功能
• 不必要地向 Internet 开放了网络连接
• 使用了弱协议或密码
• 可能允许未经授权地访问系统的其他设置或终结点

有关此威胁的详细信息，请参阅：API7:2019 安全配置错误

建议

• 正确地配置网关 TLS。 请勿使用易受攻击的协议（例如 TLS 1.0、1.1）或密码。

• 配置 API 以仅接受加密流量，例如通过 HTTPS 或 WSS 协议。

• 考虑在专用终结点后面部署 API 管理或附加到在内部模式下部署的虚拟网络。 在内部网络中，可以从专用网络内部（通过防火墙或网络安全组）和 Internet（通过反向代理）控制访问。

• 使用 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。

    • 还可以在 API 管理和后端之间应用客户端证书（相互 TLS）。 后端应执行以下操作：

      • 配置授权凭据

      • 验证证书链（如果适用）

      • 验证证书名称（如果适用）

• 对于 GraphQL 场景，使用验证 GraphQL 请求策略。 确保设置 authorization 元素以及 max-size 和 max-depth 属性。

• 不要将机密存储在策略文件或源代码管理中。 始终使用 API 管理命名值，或使用自定义策略表达式在运行时提取机密。

  • 命名值应与 Key Vault 集成，或应在 API 管理内加密，方法是将其标记为“机密”。 绝不要以纯文本命名值的形式存储机密。

• 通过需要订阅的产品发布 API。 请勿使用不需要订阅的开放产品。

• 使用 Key Vault 集成来管理所有证书；这可以集中处理证书管理，有助于简化操作管理任务，如证书续订或吊销。

• 使用自承载网关时，确保有一个流程可以定期将映像更新到最新版本。

• 将后端服务表示为后端实体。 配置授权凭据、证书链验证和证书名称验证（如果适用）。

• 使用开发人员门户时：

  • 如果选择自承载开发人员门户，请确保有一个流程可以定期将自承载门户更新到最新版本。 默认托管版本是自动更新的。

  • 使用 Microsoft Entra ID 或 Azure Active Directory B2C 进行用户注册和登录。 禁用默认用户名和密码身份验证，它们的安全性较低。

  • 向产品分配用户组，以控制门户中 API 的可见性。

• 在开发环境之外使用 DevOps 流程和基础结构即代码方法，确保 API 管理内容和配置更改的一致性，并最大程度地减少人为错误。

• 请勿使用任何已弃用的功能。

注入

接受用户数据的任何终结点都可能会受到注入攻击。 示例包括但不限于：

• 命令注入，其中恶意行动者试图更改 API 请求以在托管 API 的操作系统上执行命令

• SQL 注入，其中恶意行动者试图更改 API 请求以针对 API 依赖的数据库执行命令和查询

有关此威胁的详细信息，请参阅：API8:2019 注入

建议

• 新式 Web 应用程序防火墙 (WAF) 策略涵盖了许多常见的注入漏洞。 虽然 API 管理没有内置的 WAF 组件，但强烈建议在 API 管理实例上游（前面）部署 WAF。 例如，使用 Azure 应用程序网关。

  重要

  确保恶意行动者无法绕过托管 WAF 的网关而直接连接到 API 管理网关或后端 API 本身。 可能的缓解措施包括：网络 ACL、使用 API 管理策略根据客户端 IP 限制入站流量、删除不需要的公共访问，以及客户端证书身份验证（也称为相互 TLS 或 mTLS）。

• 使用架构和参数验证策略（如果适用），在请求到达后端 API 服务之前进一步约束和验证请求。

  与 API 定义一起提供的架构应对易受攻击的字段应用正则表达式模式约束。 每个正则表达式都应经过测试，确保对字段的约束足以减少常见的注入尝试次数。

相关信息

• 使用 Azure 应用程序网关部署 Azure API 管理

资产管理不当

与不当的资产管理相关的漏洞包括：

• 缺少适当的 API 文档或所有权信息

• 旧版 API 过多，可能缺少安全修补程序

有关此威胁的详细信息，请参阅：API9:2019 资产管理不当

建议

• 使用定义明确的 OpenAPI 规范作为导入 REST API 的源。 该规范允许封装 API 定义，包括自行记录的元数据。

  • 使用具有精确路径、数据架构、标头、查询参数和状态代码的 API 接口。 避免通配符操作。 为每个 API 和操作提供描述，包括联系人和许可证信息。

  • 避免那些与业务目标没有直接关系的终结点。 它们会不必要地增加攻击外围应用，使 API 的发展更加困难。

• 使用 API 管理中的修订和版本来管理和控制 API 终结点。 制定一个强大的后端版本控制策略，并承诺支持最大数量的 API 版本（例如，2 个或 3 个以前的版本）。 计划快速弃用并最终删除较旧的、通常不太安全的 API 版本。

• 根据环境（例如开发、测试和生产环境）使用 API 管理实例。 确保每个 API 管理实例都连接到同一环境中的相关依赖项。

• 使用标记来组织 API 和产品，并将其分组以供发布。

• 通过内置的开发人员门户发布 API 以供使用。 确保 API 文档是最新的。

• 发现未记录的或非管理的 API，并通过 API 管理公开它们，以便更好地进行控制。

日志记录和监视不足

如果日志记录和监视不足，加上与事件响应的整合缺失或无效，攻击者就能够进一步攻击系统、保持持久性、转向更多系统进行篡改，以及提取或销毁数据。 大多数违反行为研究表明，检测到违反行为的时间超过 200 天，通常是由外部方而不是通过内部流程或监视方式检测到的。

有关此威胁的详细信息，请参阅：API10:2019 日志记录和监视不足

建议

• 了解 Azure API 管理中的可观测性选项，以及用于在 Azure 中监视的最佳做法。

• 使用 Azure Monitor 监视 API 流量。

• 记录到 Application Insights 以进行调试。 在 API 管理和后端 API 之间关联 Application Insights 中的事务，以从端到端跟踪它们

• 如果需要，将自定义事件转发到事件中心。

• 在 Azure Monitor 和 Application Insights 中设置警报，例如，针对容量指标或过多的请求或带宽传输等设置警报。

• 针对自定义指标使用 emit-metric 策略。

• 使用 Azure 活动日志跟踪服务中的活动。

• 根据需要在 Azure Application Insights 和 Azure Monitor 中使用自定义事件。

• 为 Kubernetes 上的自承载网关配置 OpenTelemetry。

后续步骤

了解有关以下方面的详细信息：

• API 管理中的身份验证和授权
• API 管理的安全基线