适用于移动和 Web 的安全 API

Question

我有三个应用程序：

• REST API
• 单页 Web 应用程序
• 本机移动应用程序。

Web 应用程序和移动应用程序都使用 API 进行用户身份验证和获取用户特定数据。

我的问题是如何保护这个 API 免受 CSRF、XSS 和其他类型的攻击。

据我了解，有两种常见的身份验证策略各有利弊：

• 基于令牌的身份验证
• 基于会话/cookie 的身份验证（安全和 httponly）

基于会话/cookie 的身份验证

Cookie 容易受到 CSRF 攻击，因此为了防止这种情况，我需要实施 CSRF 令牌或类似的保护策略。对于安全的 CSRF 令牌实现，我还应该设置适当的 CORS 策略，因此外国站点无法从 API 获取 CSRF 令牌。这对于 web 应用程序来说也很好，但对于移动应用程序来说不可能，因为移动应用程序不支持 CORS（它现在有域或源头）。

基于令牌的身份验证

另一种方法是基于令牌的身份验证，它适用于移动应用程序，并且不需要 CSRF 令牌，因为它们本身验证请求的真实性。然而，在单页 Web 应用程序中没有安全的方法来存储令牌（语言环境/网络存储不安全，如果我使用 cookie，我们基本上又回到了我们的第一个问题）。

问题

所以我的问题是，我应该如何为这两个应用程序实现安全身份验证？

我目前的想法是实施这两种策略，但仅在 origin 不存在时才允许令牌身份验证，并且仅当 origin 标头存在并被 CORS 策略允许时才允许会话/cookie 身份验证。

但我绝不是这方面的专家，可能很容易误解了一些东西。任何建议或进一步的解释将非常受欢迎:)！

Answer 1

请求的真实性

另一种方法是基于令牌的身份验证，它适用于移动应用程序，并且不需要 CSRF 令牌，因为它们本身验证请求的真实性。

不能信任 Auth 令牌来验证请求的真实性，因为它们只能识别用户，而不是执行请求的真正的移动应用程序。

控制运行移动应用程序的设备的攻击者可以提取身份验证令牌以自动向 API 服务器发出请求。攻击者使用的另一种技术是为免费 wifi（机场、火车站和其他公共场所）创建一个虚假的强制门户，在那里他们欺骗登录者在他们的移动设备中安装自定义 ssl 证书，以便攻击者可以解密https 流量，从而窃取身份验证令牌并代表用户向 API 服务器执行自动请求。

实施这两种策略

我目前的想法是实施这两种策略，但仅在 origin 不存在时才允许令牌身份验证，并且仅当 origin 标头存在并被 CORS 策略允许时才允许会话/cookie 身份验证。

这可以很容易地被攻击者绕过和自动化。因此，攻击者只会使用被盗令牌发出请求，而不会在请求的标头中使用源，从而避免 Web 安全并绕过移动应用程序的安全。

建议

但我现在是这个主题的专家，可能很容易误解了一些东西。任何建议或进一步的解释将非常受欢迎:)！

我将建议您阅读有关移动 API 安全技术的这一系列文章，这将使您对如何保护 API 有很好的见解。在本文中，我们可以看到如何使用 api-keys、HMAC、证书锁定、OAUTH 来保护 API，以及如何绕过它们。虽然在移动 API 的范围内，一些技术在 Web 应用程序的上下文中是有效的。

对于网络：

使用 Strict Transport Policy 标头确保您的 Web 应用程序始终通过 https 加载。

您的 Web 应用程序应使用 CSP（内容安全策略）和报告服务，当任何策略被违反时，它会实时通知您。

如果使用 cookie，您应该启用httpOnly标志以保护它们不被 javascript 访问。此外，您还希望为 cookie 启用安全标志，以便仅将鼠标悬停在 https 连接上。还尝试通过它们所属的路径来限定 cookie，即登录页面的 cookie 应该限定在/login路径中，因此它们不会被发送到 Web 应用程序的其他页面或资产（图像、CSS 等）。

将recAptcha V3添加到您的网络应用程序的所有页面。它在后台运行，无需任何用户交互，并提供从 0 到 1 的分数，对于 1，我们更有信心提出请求的是人类。

引用谷歌：

我们很高兴推出 reCAPTCHA v3，它可以帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它根据与您网站的交互返回一个分数，并为您提供更大的灵活性来采取适当的行动。

该分数将允许在阻止非人流量方面有一定程度的信心。如果您需要更多信心，那么您可能还想使用用户行为分析 (UBA) 解决方案，该解决方案可以使用机器学习和人工智能来进一步分析传入流量并检测滥用流量。由于网络的工作方式，reCaptcha V3 和 UBA 都无法提供防弹解决方案来将请求验证为合法请求。

对于移动应用程序：

使用移动应用证明解决方案使 API 服务器知道仅接收来自真正移动应用的请求。

移动应用证明服务的作用是在运行时通过在后台运行 SDK 来保证您的移动应用未被篡改或未在有根设备中运行，该 SDK 将与运行在云中的服务通信以证明移动应用程序和设备的完整性正在运行。

成功证明移动应用程序完整性后，将发布一个短期存在的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用程序认证失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。

现在，应用程序必须随每个 API 调用发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和到期时间时才提供请求，并在验证失败时拒绝它们。

一旦移动应用程序认证服务使用的秘密不被移动应用程序知道，即使应用程序被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程。中间人攻击的目标。

移动应用证明服务已经作为Approov的 SAAS 解决方案存在（我在这里工作），它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行少量检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定提供哪些请求以及拒绝哪些请求是必要的。

可能的解决方案

所以我的问题是，我应该如何为两个应用程序实现安全身份验证？

对于网络应用程序：

• 移动和网络应用程序的 OpenID 或 OAUTH2，并且可能使用 cookie 来存储身份验证令牌，由 url 路径限定，启用 httpOnly 和安全标志。
• 进一步使用严格的 CSP 政策以及 CORS、CSFR、严格的传输政策以及我现在可能缺少的任何其他政策。
• 谷歌 reCaptcha V3。

对于移动应用程序：

• OpenID 或 OAUTH2。
• 移动应用认证解决方案。
• 证书固定。

API 将只接受包含带有 reCaptcha V3 令牌或移动应用证明 JWT 令牌的标头的请求。应拒绝任何其他请求。

在 Web 应用程序进一步处理请求的情况下，recCaptcha V3 分数（0 到 1.0）应该给出请求来自人类的信心，可能大于 0.9？您将需要使用该值并对其进行监控以找到正确的平衡。

为了能够继续处理来自移动应用程序的请求，API 服务器必须验证 JWT 令牌是否具有有效签名且未过期。

虽然 Web 请求是在尽最大努力的基础上验证的，但来自受移动证明服务保护的移动应用程序的请求只有两种可能的结果，有效或无效。