Compartir a través de

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

  • Artículo

适用于：所有 API 管理层级

注意

本文已更新，以反映 2023 年最新的 OWASP API 安全性十大威胁列表。

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

OWASP API 安全项目的重点是制定策略和解决方案来了解并缓解 API 的特有漏洞和安全风险。 本文讨论使用 Azure API 管理来缓解 OWASP 在其 2023 年列表中确定的十大 API 威胁的最新建议。

对象级别授权中断

对于未使用适当级别的授权保护的 API 对象，可能会因为较弱的对象访问标识符而容易发生数据泄漏和未经授权的数据操作。 例如，攻击者可以利用一个可迭代的整数对象标识符。

有关此威胁的详细信息，请参阅：API1:2023 对象级别授权中断

建议

  • 实现对象级别授权的最佳位置是在后端 API 本身。 在后端，可以在请求（或对象）级别做出正确的授权决策，如果适用的话，使用适用于域和 API 的逻辑。 考虑这样一个场景：一个给定的请求可能会根据请求者的权限和授权在响应中产生不同级别的详细信息。

  • 如果在后端无法更改当前易受攻击的 API，可以将 API 管理用作一种回退方式。 例如：

    • 如果没有在后端实现对象级别授权，则使用自定义策略来实现该授权。

    • 实现自定义策略，将标识符从请求映射到后端，从后端映射到客户端，这样内部标识符就不会公开。

      在这些情况下，自定义策略可以是带查找功能的策略表达式（例如，字典），也可以通过 send-request 策略与其他服务集成。

  • 对于 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 策略对较短的时间时段应用限制。 对敏感终结点（如密码重置、登录或注册操作）或使用大量资源的终结点应用更严格的速率限制策略。
  • 使用 quota-by-key 或 quota-limit 策略来控制允许的 API 调用数或较长时间范围内的带宽。
  • 使用内置缓存优化性能，从而减少某些操作的 CPU、内存和网络资源的消耗。
  • 应用验证策略。
    • 在 validate-content 策略中使用 max-size 属性来强制实施请求和响应的最大大小
    • 在 API 规范中定义架构和属性，例如字符串长度或最大数组大小。 使用 validate-content、validate-parameters 和 validate-headers 策略来对请求和响应强制实施这些架构。
    • 对 GraphQL API 使用 validate-graphql-request 策略并配置 max-depth 和 max-size 参数。
    • 在 Azure Monitor 中配置针对用户过度使用数据的警报。
  • 最大程度地减少后端服务响应所需的时间。 后端服务响应所需的时间越长，API 管理中占用连接的时间就越长，从而减少了可在给定时间范围内提供的请求数。
  • 应用 CORS 策略来控制允许加载通过 API 提供的资源的网站。 为了避免过于宽松的配置，请勿在 CORS 策略中使用通配符值 (*)。
  • 虽然 Azure 具有平台级保护和针对分布式拒绝服务 (DDoS) 攻击的增强保护，但可以通过在 API 管理前端部署机器人防护服务（例如Azure 应用程序网关、Azure Front Door 或 Azure DDoS 防护）来改进对 API 的应用程序（第 7 层）保护。 将 Web 应用程序防火墙 (WAF) 策略与 Azure 应用程序网关或 Azure Front Door 配合使用时，请考虑使用 Microsoft_BotManagerRuleSet_1.0。

功能级别授权中断

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

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

建议

  • 默认情况下，使用订阅密钥或“all-APIs-level”授权策略来保护 API 管理中的所有 API 终结点。 如果适用，请为特定 API 或 API 操作定义其他授权策略。
  • 使用策略验证 OAuth 令牌。
    • 使用 validate-azure-ad-token 策略验证 Microsoft Entra 令牌。 指定所有必需的声明，并指定授权的应用程序（如果适用）。
    • 要验证并非由 Microsoft Entra 颁发的令牌，请定义 validate-jwt 策略并强制执行所需的令牌声明。 如果可能，要求提供过期时间。
    • 如果可能，请使用加密令牌或列出特定的应用程序以供访问。
    • 监视和审查由于缺少授权而被拒绝的请求。
  • 使用 Azure 虚拟网络或专用链接对 Internet 隐藏 API 终结点。 详细了解 API 管理的虚拟网络选项。
  • 请勿定义通配符 API 操作（即以 *  为路径的“全能”API）。 确保 API 管理仅为显式定义的终结点请求提供服务，而对未定义的终结点的请求则被拒绝。
  • 不要通过不需要订阅的开放产品发布 API。
  • 如果客户端 IP 是已知的，请使用 ip-filter 策略仅允许来自已授权 IP 地址的流量。
  • 使用 validate-client-certificate 策略来强制客户端提供给 API 管理实例的证书与指定的验证规则和声明匹配。

不受限制地访问敏感业务流

API 可以向消费应用程序公开多种功能。 API 作者必须了解 API 提供的业务流和关联的敏感度。 如果公开敏感流的 API 未实施适当的保护，则业务会面临更大的风险。

有关此威胁的详细信息，请参阅：API6:2023 不受限制地访问敏感业务流

建议

  • 根据客户端指纹减少或阻止访问。 例如，配合使用 return-response 策略和 choose 策略，以根据 User-Agent 标头或其他标头的一致性来阻止来自无外设浏览器的流量。
  • 使用 validate-parameters 策略强制请求标头符合 API 规范。
  • 使用 ip-filter 策略来仅允许来自已知 IP 地址的请求或拒绝来自特定 IP 的访问。
  • 使用专用网络功能限制与内部 API 的外部连接。
  • 使用 rate-limit-by-key 策略根据用户标识、IP 地址或其他值来限制 API 消耗峰值。
  • 使用 Azure 应用程序网关或 Azure DDoS 防护服务进行前端 API 管理，以检测和阻止机器人流量。

服务器端请求伪造

当 API 根据 API 调用方传递的 URL 值提取下游资源而未进行适当的验证检查时，可能会出现服务器端请求伪造漏洞。

有关此威胁的详细信息，请参阅：API7:2023 服务器端请求伪造

建议

  • 如果可能，请不要使用客户端有效负载中提供的 URL，例如，将其作为后端 URL、send-request 策略或 rewrite-url 策略的参数。
  • 如果 API 管理或后端服务将请求有效负载中提供的 URL 用于业务逻辑，请在 API 管理中使用策略（例如 choose 策略和策略表达式）来定义并强制使用主机名、端口、媒体类型或其他属性的有限列表。
  • 在 forward-request 和 send-request 策略中定义 timeout 属性。
  • 使用验证策略来验证和清理请求和响应数据。 如果需要，请使用 set-body 策略来处理响应，并避免返回原始数据。
  • 使用专用网络限制连接。 例如，如果不需要公开 API，请限制来自 Internet 的连接以减少攻击面。

安全配置错误

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

  • 缺少安全强化措施
  • 启用了不必要的功能
  • 不必要地向 Internet 开放了网络连接
  • 使用了弱协议或密码

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

建议

  • 正确地配置网关 TLS。 请勿使用易受攻击的协议（例如 TLS 1.0、1.1）或密码。
  • 配置 API 以仅接受加密流量，例如通过 HTTPS 或 WSS 协议。 可以使用 Azure Policy 来审核并强制执行此设置。
  • 考虑在专用终结点后面部署 API 管理或附加到在内部模式下部署的虚拟网络。 在内部网络中，可以从专用网络内部（通过防火墙或网络安全组）和 Internet（通过反向代理）控制访问。
  • 使用 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。
  • 还可以在 API 管理和后端之间应用客户端证书（相互 TLS）。 后端应执行以下操作：
    • 配置授权凭据
    • 验证证书链（如果适用）
    • 验证证书名称（如果适用）
    • 对于 GraphQL 场景，使用 validate-graphQL-request 策略。 确保设置 authorization 元素以及 max-size 和 max-depth 属性。
  • 不要将机密存储在策略文件或源代码管理中。 始终使用 API 管理命名值，或使用自定义策略表达式在运行时提取机密。 命名值应与 Azure Key Vault 集成，或应在 API 管理内加密，方法是将其标记为“机密”。 绝不要以纯文本命名值的形式存储机密。
  • 通过需要订阅的产品发布 API。 请勿使用不需要订阅的开放产品。
  • 确保 API 需要订阅密钥，即使所有产品都配置为需要订阅密钥。 了解详细信息
  • 要求对所有产品进行订阅审批，并仔细查看所有订阅请求。
  • 使用 Key Vault 集成来管理所有证书。 这可以集中管理证书，有助于简化操作管理任务，如证书续订或吊销。 使用托管标识对密钥保管库进行身份验证。
  • 使用自承载网关时，确保有一个流程可以定期将映像更新到最新版本。
  • 将后端服务表示为后端实体。 配置授权凭据、证书链验证和证书名称验证（如果适用）。
  • 如果可能，请使用凭据管理器或托管标识对后端服务进行身份验证。
  • 使用开发人员门户时：
    • 如果选择自承载开发人员门户，请确保有一个流程可以定期将自承载门户更新到最新版本。 默认托管版本是自动更新的。
    • 使用 Microsoft Entra ID 或 Azure Active Directory B2C 进行用户注册和登录。 禁用默认用户名和密码身份验证，它们的安全性较低。
    • 向产品分配用户组，以控制门户中 API 的可见性。
  • 在开发环境之外使用 DevOps 流程和基础结构即代码方法，确保 API 管理内容和配置更改的一致性，并最大程度地减少人为错误。
  • 请勿使用任何已弃用的功能。

库存管理不当

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

  • 缺少适当的 API 文档或所有权信息
  • 旧版 API 过多，可能缺少安全修补程序

有关此威胁的详细信息，请参阅：API9:2023 库存管理不当

建议

  • 使用定义明确的 OpenAPI 规范作为导入 REST API 的源。 该规范允许封装 API 定义，包括自行记录的元数据。
  • 使用具有精确路径、数据架构、标头、查询参数和状态代码的 API 接口。 避免通配符操作。 为每个 API 和操作提供描述，包括联系人和许可证信息。
  • 避免那些与业务目标没有直接关系的终结点。 它们会不必要地增加攻击外围应用，使 API 的发展更加困难。
  • 使用 API 管理中的修订和版本来管理 API 更改。 制定一个强大的后端版本控制策略，并承诺支持最大数量的 API 版本（例如，2 个或 3 个以前的版本）。 计划快速弃用并最终删除较旧的、通常不太安全的 API 版本。 确保在所有可用 API 版本中都实现了安全控制。
  • 使用不同的 API 管理服务来分离环境（例如开发、测试和生产）。 确保每个 API 管理服务都连接到同一环境中的相关依赖项。 例如，在测试环境中，测试 API 管理资源应连接到测试 Azure Key Vault 资源和后端服务的测试版本。 使用 DevOps 自动化和基础结构即代码做法来帮助维护环境之间的一致性和准确性，并减少人为错误。
  • 使用工作区隔离对 API 和相关资源的管理权限。
  • 使用标记来组织 API 和产品，并将其分组以供发布。
  • 通过开发人员门户发布 API 以供使用。 确保 API 文档是最新的。
  • 发现未记录的或非管理的 API，并通过 API 管理公开它们，以便更好地进行控制。
  • 使用 Azure API 中心来维护全面、集中的 API、版本和部署清单，即使 API 未在 Azure API 管理中进行管理。

不安全地使用 API

通过下游集成获取的资源往往比来自调用方或最终用户的 API 输入更受信任。 如果未应用适当的清理和安全标准，则即使通过受信任的服务提供集成，API 也可能易受攻击。

有关此威胁的详细信息，请参阅：API10:2023 不安全地使用 API

建议

  • 请考虑使用 API 管理作为后端 API 集成的下游依赖项的外层。
  • 如果下游依赖项前面有 API 管理，或者如果通过 API 管理中的 send-request 策略来使用下游依赖项，请使用本文档其他部分中的建议来确保其安全且受控的使用，包括：
    • 确保启用安全传输，并强制实施 TLS/SSL 配置
    • 如果可能，请使用凭据管理器或托管标识进行身份验证
    • 使用“rate-limit-by-key”和“quota-limit-by-key”策略控制使用
    • 使用“validate-content”和“validate-header”策略记录或阻止不符合 API 规范的响应
    • 使用“set-body”策略转换响应，例如移除不必要的信息或敏感信息
    • 配置超时并限制并发

相关内容

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