适用于移动设备和 Web 的安全 API

Posted 2023-02-22

【中文标题】适用于移动设备和 Web 的安全 API

【英文标题】：Secure API for both mobile and web

【发布时间】：2019-06-06 07:28:00

【问题描述】：

我有三个应用程序：

REST API 单页网页应用 原生移动应用。

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

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

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

基于令牌的身份验证 基于会话/cookie 的身份验证（安全且仅限 http）

基于会话/cookie 的身份验证

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

基于令牌的身份验证

替代方案是基于令牌的身份验证，它适用于移动应用程序，并且无需 CSRF 令牌，因为它们本身可以验证 请求的真实性。但是，在单页 Web 应用程序中存储令牌没有安全的方法（区域设置/网络存储不安全，如果我使用 cookie，我们基本上会回到我们的第一个问题）。

问题

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

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

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

【参考方案1】：

请求的真实性

替代方案是基于令牌的身份验证，它适用于移动应用程序，并且无需 CSRF 令牌，因为它们本身可以验证请求的真实性。

无法信任身份验证令牌来验证请求的真实性，因为它们仅识别用户，而不是真正的移动应用程序发出请求。

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

实施这两种策略

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

这很容易被攻击者绕过和自动化。所以攻击者会 仅使用被盗令牌发出请求，而不使用 请求的标头，从而避免 Web 的安全性并绕过那些 对于移动应用程序。

建议

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

我会建议您阅读 this series 有关移动 API 安全技术的文章，这将使您深入了解如何保护 API。在本文中，我们可以看到如何使用 api-keys、HMAC、证书固定、OAUTH 来保护 API 以及如何绕过它们。虽然在移动 API 的范围内，一些技术在网络应用的上下文中是有效的。

对于网络：

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

您的网络应用应使用带有report service 的 CSP（内容安全政策），当违反任何政策时，您会实时知道。

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

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

引用谷歌：

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

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

对于移动应用：

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

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

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

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

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

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

可能的解决方案

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

对于网络应用：

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

对于移动应用：

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

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

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

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

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

【讨论】：

非常感谢您的详尽回答！

@railsdev 欢迎来到 *** 并感谢您的友好评论。请始终记住为您喜欢的答案投票，然后将最能解决您的问题的答案标记为已接受。

@Exadra37 有据可查的答案/解决方案。一个简单的问题，如果用户更改了他/她的密码怎么办？是否所有设备上的所有令牌都无效。这是否意味着在每个设备级别上跟踪令牌？

是的，一旦他更改密码，您应该使所有当前令牌无效以进行用户身份验证，为此您需要跟踪后端中所有已发布的令牌。

@Exadra37 谢谢。通过您讨论的方法，此处也适用短期访问和长期刷新令牌。在哪里可以使用访问令牌来授权用户访问某些资源，以及在过期时使用刷新令牌来检索访问令牌？