社区首页 >专栏 >5步实现军用级API安全

5步实现军用级API安全

云云众生s

发布于 2024-04-23 01:42:18

1440

文章被收录于专栏：云云众生s云云众生s

保护数字服务的最有效方法是从坚实的基础开始，然后尽可能地将安全性提升到军事级别。

译自 5 Steps Toward Military-Grade API Security，作者 Gary Archer。

针对软件的网络攻击正变得越来越复杂。技术工具的进步为恶意攻击者提供了多种自动化攻击方式。对于许多提供数字服务的组织而言，应对威胁可能令人望而生畏。当您资源有限且希望专注于业务目标时，如何最好地管理安全性？

让我解释一下一种迭代方法，以采用“军用级”安全思维。我将表明，这并不需要您成为一个将主要资源分配给打击网络威胁的富裕组织。相反，军用级是一种方法，您可以在其中持续审查您的安全性并在切实可行时对其进行加强。示例可能是使用更强的加密形式来保护连接、更安全的用户身份验证形式或处理特定威胁的较新的安全设计模式。

主要目标应该是能够以抵御未来威胁的方式保护您的数字资产的架构。保护数字服务的最佳方法是从坚实的基础开始，然后尽可能地将安全性提升到军用级。这使您能够保持安全性处于最新状态。

步骤 1：使用安全标准

您应该根据许多专家审查的标准实施应用程序安全性。RFC 6749 中的 OAuth 2.0 授权框架提供了这样的设置。OAuth 是一系列规范，可映射到组织的安全用例。这些标准不断发展，以跟上新的威胁。

OAuth 以使用称为访问令牌的 API 消息凭据来保护数据为中心。此令牌由称为授权服务器的专用安全组件颁发。访问令牌旨在根据业务权限锁定，并由授权服务器加密签名。客户端从授权服务器请求访问令牌，然后将访问令牌发送到 API 端点。面向用户的应用程序在收到访问令牌时在授权服务器触发用户身份验证。

使用 OAuth 使您能够实施零信任架构，该架构同时考虑了 API 和前端应用程序的最佳实践。示例部署如下图所示，其中 API 和授权服务器托管在 API 网关之后。API 需要 JSON Web 令牌 (JWT) 格式中的访问令牌，并在每个 API 请求上对令牌进行加密验证。然后，API 信任访问令牌中的声明并将其用于业务授权。

在此示例中，还遵循了客户端最佳实践。互联网客户端接收不透明（引用）访问令牌，这些令牌不会泄露访问令牌数据，因为该数据仅供 API 使用。基于浏览器的应用程序在进行 API 请求时通常会发送仅限 HTTP 的 cookie，而不是直接使用访问令牌。

API 网关是一种托管最佳实践。仅将网关暴露给互联网，而不是直接暴露 API 和授权服务器。然后，网关可以执行常见的安全检查，例如速率限制。它还可以在 API 请求期间执行令牌转换，以将从客户端发送的不透明令牌或 cookie 转换为 JWT 访问令牌。这统一了您的 API 安全性，以便 API 仅需要接收 JWT 访问令牌，无论客户端如何。

当一个组织不熟悉 OAuth 时，由于安全性的分布式特性，在实施其流程时存在学习曲线。理解编码技术并部署整个系统需要一些时间，但一旦您拥有基于令牌的架构，您的基本设置将使您能够发展您的安全性以使用军用级功能。

步骤 2：加强 API 凭据

OAuth 可以使用强安全配置文件，例如 FAPI 2.0 提供的配置文件。在某些行业（例如银行和医疗保健）中，实施此类配置文件可能是强制性的。还建议其他组织使用强安全性。

首先，您应该专注于强大的 API 访问控制。在使用 OAuth 时，攻击者无法为您的 API 创建有效的访问令牌，因为这样做需要窃取授权服务器的加密私钥。然而，默认情况下，访问令牌是持有者令牌，这意味着 API 无法区分合法调用者和恶意调用者。因此，如果攻击者以某种方式截获了访问令牌，他们可以将其发送到您的 API 以获取对数据的访问权限。

为防止这种情况，请尽可能使用持有证明令牌。一种常见的用例是向业务合作伙伴提供 API。在这种情况下，您可以使用 RFC 8705 标准指定的 OAuth 2.0 互 TLS 客户端身份验证和证书绑定访问令牌。客户端使用客户端证书在授权服务器上进行身份验证，并获取绑定到客户端证书的访问令牌。在后续 API 请求中，客户端必须在每次 API 请求中发送相同的客户端证书以及访问令牌。然后，API 可以区分提供私钥持有证明的合法请求和不提供私钥持有证明的恶意请求，并拒绝恶意调用者的访问。

您可以考虑的另一种持有证明选项（不需要您管理客户端证书）是在应用程序层演示持有证明 (DPoP)。它的工作方式在技术上与客户端证书类似，只是客户端以 JSON Web Key (JWK) 格式生成运行时密钥对。为了进行身份验证，客户端创建一个证明 JWT，并使用其私钥对其进行签名，并且访问令牌绑定到客户端的持有证明密钥。在每次 API 请求中，客户端都必须发送一个新的证明 JWT，该 JWT 由相同的私钥签名。然后，API 可以再次区分提供私钥持有证明的合法请求和不提供私钥持有证明的恶意请求，并拒绝恶意调用者的访问。

由于持有证明验证是一个通用流程，因此您可以通过编写一个小型 API 网关插件在 API 网关中实现它。这可以帮助您在多个 API 之间共享此类逻辑，同时保持 API 代码以业务为中心。

步骤 3：加强客户端安全性

在评估客户端安全性时，您必须解决特定于环境的威胁。在浏览器中，军用级从确保针对令牌盗窃的最佳保护开始，其中恶意 JavaScript 威胁，也称为跨站点脚本 (XSS)，是最令人担忧的问题。为了减少 XSS 漏洞的影响，建议使用最新且最安全的仅 HTTP SameSite Cookie 将 OAuth 令牌传输到您的 API。

使用后端到前端 (BFF) 组件向 JavaScript 应用程序颁发 Cookie。BFF 在获取访问令牌时也应使用客户端凭据。如果您使用 OAuth 来保护单页应用程序 (SPA)，则令牌处理程序模式可以成为一种便捷的选择，以便在影响较小的情况下启用此功能。然后，实用程序 API 会代表其 SPA 颁发 Cookie，而不会对您的 Web 架构产生不利影响。

在 OAuth 架构中，客户端通过运行 OAuth 流程来获取访问令牌。为了对用户进行身份验证，客户端使用 OpenID Connect 标准并运行代码流程。客户端向授权服务器发送请求参数并接收响应参数。但是，这些参数可能会被篡改。例如，攻击者可能会重放请求并更改范围值以尝试提升权限。

为了防止请求篡改，您可以使用 RFC 9126 中的推送授权请求 (PAR)。这只是代码流程的另一种形式，需要进行一些小的代码更改。要使用 PAR，客户端首先向授权服务器发送 POST 请求以及客户端凭据。然后，客户端可以接收一个 request_uri，并在浏览器重定向期间使用它。为了防止重放攻击，每个 request_uri 只可使用一次。

保护响应的等效解决方案是使用 OpenID Foundation 的 JWT 安全授权响应模式 (JARM)。授权响应参数在签名的 JWT 中接收，因此无法被篡改。您可以将 PAR 和 JARM 一起使用，而无需任何额外的密钥管理，因为只有授权服务器的密钥用于对响应 JWT 进行签名。

步骤 4：加强用户身份验证

OAuth 标准未提供有关如何加强用户身份验证的建议。然而，在实践中，授权服务器应允许面向用户的应用程序对用户登录使用可靠的安全性，例如通过应用多因素身份验证。弱身份验证方法容易受到帐户接管攻击，其中恶意方可以访问用户的数据。

从淘汰密码开始，因为它们是许多安全漏洞的根源。例如，网络钓鱼攻击可能会从一个网站窃取用户的密码，然后在另一个网站上成功使用它。更糟糕的是，网上发生了许多服务器漏洞事件，泄露了许多用户的密码。

军用级替代方案将基于非对称加密，其中用于一个服务器来源的密钥不能在另一个服务器上使用。这意味着用户在本地保留其私钥，而服务器只处理公钥。这种类型的解决方案具有防网络钓鱼功能，并且不需要服务器存储用户机密。

对于许多组织来说，强化用户身份验证的最便捷方法是使用基于 FIDO 联盟的 WebAuthn 范的 Passkeys。现在由主流桌面和移动操作系统提供 Passkeys，因此没有困难的用户先决条件。 Passkeys 还可以使用与密码相同的帐户恢复行为。

步骤 5：使用可扩展安全性

您的应用程序安全性不是一成不变的，它会随着发现新的威胁和设计最佳实践来缓解这些威胁而不断发展。您偶尔需要引入额外的安全组件或与第三方系统集成。因此，您的安全架构应该是可扩展的，并且能够在新的安全功能可用时使用它们。

在未来，可能会出现更强大的方式来实现 OAuth 安全的移动应用程序。目前的一个担忧是，它们通常无法安全地存储客户端凭据，因此它们通过遵循 RFC 8252 中发布的 OAuth for Native Apps 作为 OAuth 公共客户端运行。最安全的选择是使用声明的基于 HTTPS 方案的重定向 URI，以防止恶意应用程序冒充实际应用程序。然而，较新的 Android 和 iOS 设备现在支持可以防止冒充的客户端证明功能。应用程序可以加密签名一个质询来证明其身份，并从云服务接收 JWT 响应。此 JWT 可以在代码流开始时发送到授权服务器，以启用强化的移动流。

身份验证将继续需要随着时间的推移而强化。虽然通行密钥提高了密码的安全性，并且适用于许多数字服务，但您并不知道用户是谁。当您需要用户身份的真实证明时，您的授权服务器应支持可扩展性，以使您能够与提供身份证明的第三方系统集成。将来，支持使用数字凭据进行身份验证的授权服务器将使您能够从受信任的第三方接收用户身份的真实证明。

为了对抗自动化攻击，我预计跟踪使用模式的系统将在安全决策中得到更广泛的应用。这些模式可以在用户身份验证和 API 访问期间应用。基于策略的方法可能是实现这种类型的动态授权要求的首选方式。Open Policy Agent 等策略引擎可能会查阅使用数据并向应用程序返回风险评分，然后可以使用该评分来做出安全决策。

当然，这些类型的集成通常只需要偶尔进行一次。重要的行为是您的设置能够适应新要求并在需要时插入新的安全行为。