通过安全令牌进行 API 身份验证的最佳实践（Node.js 服务器和移动应用程序）

Posted 2023-03-10

【中文标题】通过安全令牌进行 API 身份验证的最佳实践（Node.js 服务器和移动应用程序）

【英文标题】：Best practice for API auth by security token (Node.js server and Mobile apps)

【发布时间】：2020-09-30 22:07:20

【问题描述】：

通常我们通过 JWT（访问和刷新令牌）保护移动 API。但是我们只是面临这样的情况，即我们的应用程序必须 100% 可供用户使用，即使 JWT 令牌已过期。 （它是一些紧急的东西）。并且用户/应用程序不能等待重新登录并获取新的 JWT 代码..

问题：在不从后端获取新令牌的情况下，长时间（...永远）保护 API 调用的最佳方法是什么。当每个请求使用共享密钥对移动应用程序进行加密时，我看到了几次变体，每个请求的当前日期时间附件......但我不确定它是否是一个好的解决方案，至少它会有性能问题（加密的操作时间/解密请求）。

【参考方案1】：

API 用户 JWT 令牌

通常我们通过 JWT（访问和刷新令牌）保护移动 API。 并且用户/应用程序不能等待重新登录并获取新的 JWT 代码..

这只允许您的 API 服务器知道 谁 在请求中，而不是 什么 正在执行请求。

访问 API 服务器的 WHO 和 WHAT 的区别

我写了一系列关于 API 和移动安全的文章，在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 谁 和 What 访问你的API 服务器，但我将在此处提取其中的要点：

what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？

谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

因此，将 谁 视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将 What 视为制作该数据的软件代表用户请求。

您的问题

但我们只是遇到了这样的情况，即我们的应用程序必须 100% 可供用户使用，即使 JWT 令牌已过期。 （它是一些紧急的东西）。

您发现自己需要解决一个非常具有挑战性的问题，但并非不可能，我们的开发人员喜欢这种类型的挑战 :)。

传入请求

现在我希望你已经很好地理解了谁和什么访问你的API服务器之间的区别，因此你可能已经意识到你不能绝对信任任何请求到达您的 API 服务器。因此，您必须将任何请求视为对您的 API 服务器的潜在攻击，直到证明相反，也就是您在法庭上是无辜的，直到证明相反；）。

请求加密

但我不确定它是否是一个好的解决方案，至少它会有性能问题（加密/解密请求的操作时间）。

就像你去餐厅时不能期待免费的晚餐一样，你不能指望在不增加一些毫秒时间的情况下为任何应用程序增加安全性；）。

当每个请求使用共享密钥对移动应用程序进行加密时，我看到了几次变体，每个请求的当前日期时间附件...

这种方式更适合保证请求中的数据完整性。换句话说，中间人 (MitM) 攻击无法看到或修改它，但不会向 API 服务器提供任何保证，该服务器确实来自您所期望的 what，您的移动应用，因为攻击者可以从您的移动应用中获取真正的请求并重放它。

另外，攻击者可以使用与我在文章中演示的方法类似的方法，通过静态二进制分析对您的移动应用程序进行逆向工程以提取加密密钥 How to Extract an API key from a Mobile App with Static Binary Analysis:

可用于逆向工程的开源工具种类繁多，我们在本文中确实无法触及这个主题的表面，而是将重点使用Mobile Security Framework(MobSF) 来演示如何逆向工程我们的移动应用程序的 APK。 MobSF 是一组开源工具，它们在一个有吸引力的仪表板中展示其结果，但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。

如果通过静态分析进行逆向工程不能解决问题，那么攻击者可以使用检测框架在运行时挂钩到您的移动应用程序并提取用于加密请求的密钥，因此他将能够生成自己的请求并让您的 API 服务器相信 发出请求的 是您的移动应用程序，而实际上现在拥有加密密钥的是攻击者。

检测框架的一个很好的例子是Frida：

将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。

证明 API 请求是可信的

问题：在不从后端获取新令牌的情况下，长时间（...永远）保护 API 调用的最佳方法是什么。

我希望现在您已经意识到，通过使用一系列可用的逆向工程技术和开源工具，攻击者一直想在您的移动应用程序周围进行探索，以了解它的加固技术以及如何绕过它们以将您的 API 服务器冒充为它真正期望的，即您的移动应用。最重要的是，您无法使用移动应用程序中附带的静态解决方案“永远”保护您的 API 服务器。

保护 API 服务器不是一件容易的事，您应该在您的市场上应用尽可能多的安全层，并且是法律要求的。

您的问题的一个可能解决方案是应用移动应用程序证明概念，您可以在this answer 中阅读更多信息，我给了另一个问题，我建议您特别注意Securing the API Server 和@部分987654330@.

您想加倍努力吗？

在回答任何安全问题时，我总是喜欢参考 OWASP 基金会的出色工作，因此这个答案也不例外 :)

对于移动应用

OWASP Mobile Security Project - Top 10 risks

OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

OWASP - Mobile Security Testing Guide:

移动安全测试指南 (MSTG) 是一本用于移动应用安全开发、测试和逆向工程的综合手册。

对于 APIS

OWASP API Security Top 10

OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。

【参考方案2】：

您需要做的第一件事是风险评估，基本上：

你完全信任什么 您可以以某种方式信任的东西 你不能信任的东西

在第一类中，您可能拥有来自第三方或由用户输入的身份验证令牌。

在第二种情况下，您可能有一些东西可以识别您的移动设备，但第三方不容易知道（例如设备的工厂 ID，或传入的 IP）

在第三个中，您将获得设备发送的信息，例如“这是正在连接的用户”

根据此分析，您最终会得到一些解决方案。举个虚构的例子：

当调用者通过多重身份验证识别时对数据的完全访问权限 从已知 IP 连接时信息有限 使用正确的 JSON 架构访问时的公共信息 拒绝难以理解的请求

没有奇迹，在某些时候你需要信任某些东西——关键是攻击者获取或修改这些信息的难易程度。

【讨论】：

我们将拥有独一无二的设备 ID。我不确定，但也许根据这个设备 ID 和时间戳为每个请求添加“签名”是正常的。

@MaxVinogradov：这完全取决于您的威胁概况。你认为有人能猜出这个ID吗？还是列举一下？有权使用该设备的人呢？他们可以泄漏吗？当您有一个想法时，您需要通过一系列“最坏的情况会发生什么？”的问题来运行它。心里。这通常是您与安全团队一起完成的工作（因为他们应该在这种情况下拥有更多经验）