React Native - 存储 api 密钥

Question

我有由 react native 创建的移动应用程序，我有后端服务器，当我们请求正确的端点并传递正确的 api 密钥时，它可以启动支付会话或发送电子邮件。现在我将后端 api 密钥存储在 .env 文件中，但这不是一种安全方式 - https://reactnative.dev/docs/security#storing-sensitive-info

我不希望每个知道端点并且会发现 api 密钥的人都可以使用我的后端 API，例如通过 Postman 请求。

在这种情况下，我可以做些什么来保护我的后端 API？

Answer 1

.env 文件中的秘密

首先，您需要记住，一件事是防止机密从您运行后端代码或构建移动应用二进制版本的环境中泄露，另一件事是在备份到移动应用二进制时保护机密或当移动应用程序在移动设备中运行时。

现在我将后端 api 密钥存储在 .env 文件中，但这不是一种安全方式 - https://reactnative.dev/docs/security#storing-sensitive-info

使用.env文件是一种广泛使用的做法，以避免代码中的硬编码秘密，因此该文件必须始终存在于.gitignore文件中。存在替代方案，例如使用保险库：

Harshicop Vault

Vault 是一种用于安全访问机密的工具。机密是您想要严格控制访问的任何内容，例如 API 密钥、密码、证书等。Vault 为任何机密提供统一的界面，同时提供严格的访问控制并记录详细的审计日志。

现在，这种方法对于在服务器中运行的代码非常有效，但是对于移动应用程序开发来说，唯一的优势是您没有在移动应用程序的源代码中硬编码的秘密，因此您不会得到它在您的 Git 存储库中泄露（前提是您没有忘记在 .gitignore 中包含 .env），但是您将在移动应用程序二进制文件中以普通字符串的形式获取秘密，这很容易通过静态二进制分析进行逆向工程，如我在我的文章 How to Extract an API key from a Mobile App with Static Binary Analysis 中描述：

可用于逆向工程的开源工具范围非常广泛，我们无法在本文中触及该主题的表面，而是将重点放在使用移动安全框架 (MobSF)来演示如何逆向工程我们的移动应用程序的 APK。MobSF 是一个开源工具的集合，它们在一个有吸引力的仪表板中展示他们的结果，但是在 MobSF 和其他地方使用的相同工具可以单独使用来实现相同的结果。

正如我在文章中所说，您甚至可以strings在 Linux 中使用该命令来提取它。

编排层

https://reactnative.dev/docs/security#storing-sensitive-info

请不要遵循他们提出的建议，除非：

如果您必须拥有 API 密钥或秘密才能从您的应用程序访问某些资源，那么最安全的处理方法是在您的应用程序和资源之间构建一个编排层。这可以是无服务器功能（例如使用 AWS Lambda 或 Google Cloud Functions），它可以使用所需的 API 密钥或秘密转发请求。API 使用者无法像应用程序代码中的机密一样访问服务器端代码中的机密。

为什么？那么您如何保护对该编排层的访问？从他们的描述来看，它似乎没有受到保护，因此攻击者需要做的就是在他控制的设备上对您的移动应用程序执行中间人攻击，并了解应用程序如何与这个编排层通信，然后我们就可以做在移动应用程序之外也是如此。最糟糕的是，这个编排层实际上是对世界开放的，因此任何人都可以做你害怕的事情：

我不希望每个知道端点并且会发现 api 密钥的人都可以使用我的后端 API，例如通过 Postman 请求。

反向代理

让我们看看除非位...

现在，如果您使用秘密保护对编排层的访问，那么您几乎会回到零，但是如果您的应用程序与多个后端进行通信，例如使用多个第三方 API，然后使用反向代理（编排层）是一种很好的方法，正如我在使用反向代理保护第三方 API 的文章中所述：

在本文中，您将首先了解什么是第三方 API，以及为什么不应该直接从您的移动应用程序中访问它们。接下来，您将了解什么是反向代理，然后了解何时以及为何应使用它来保护对移动应用程序中使用的第三方 API 的访问。

保护秘密

到现在为止，您可能想知道如何保护在移动应用程序中在运行时访问反向代理的秘密？？？

在我上面链接的用于提取 API 密钥的文章中，您可能已经注意到，我使用 repo android-hide-secrets演示了一些将它们隐藏在二进制文件中的不同方法，这是使用本机 C 代码最有效的方法。虽然这使得使用静态二进制分析很难提取秘密，但它并没有为您提供任何针对运行时攻击的保护，就像可以使用检测框架执行的攻击一样，例如Frida：

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

借助检测框架，您甚至可以利用 iOS 和 Android 操作系统提供的所有最先进技术窃取加密存储在移动设备中的秘密，因为攻击者将钩住返回未加密秘密以供使用的函数在请求中。

这很可怕，因为检测框架有无限可能在运行时攻击移动应用程序，人们可能认为它注定无法在运行时保护代码，但它还没有结束，您仍然可以诉诸移动应用程序证明概念，为此，我建议您阅读我对如何为移动应用程序保护 API REST的问题给出的答案？，尤其是保护 API 服务器和可能的更好解决方案部分。

移动应用证明概念可能是您正在寻找的这个问题的答案：

在这种情况下，我可以做些什么来保护我的后端 API？

请始终记住，安全就是在您负担得起或法律要求的范围内添加尽可能多的防御层。这不是什么新鲜事，只要记住城堡防御是如何由多层组成的。

你想走得更远吗？

在对安全问题的任何回答中，我总是喜欢参考 OWASP 基金会的出色工作。

用于APIS

OWASP API 安全前 10 名

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

对于移动应用程序

OWASP 移动安全项目 - 十大风险

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

OWASP - 移动安全测试指南：

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