我有由 react native 创建的移动应用程序，我有后端服务器，当我们请求正确的端点并传递正确的 api 密钥时，它可以启动支付会话或发送电子邮件。现在我将后端 api 密钥存储在 .env 文件中，但这不是一种安全方式 - https://reactnative.dev/docs/security#storing-sensitive-info
我不希望每个知道端点并会发现 api 密钥的人都可以使用我的后端 API，例如通过 Postman 请求。
在这种情况下，我可以做些什么来保护我的后端 API？
【问题讨论】：
标签： android ios react-native api mobile
首先，您需要记住，一件事是防止机密从您运行后端代码或构建移动应用二进制版本的环境中泄露，另一件事是在机密被备份到移动应用二进制文件或移动应用在移动设备中运行时。
现在我将后端 api 密钥存储在 .env 文件中，但这不是一种安全方式 - https://reactnative.dev/docs/security#storing-sensitive-info
.env 文件的使用被广泛用于避免在代码中硬编码机密，因此该文件必须始终存在于 .gitignore 文件中。存在替代方案，例如使用保险库：
Vault 是一种用于安全访问机密的工具。机密是您想要严格控制访问的任何内容，例如 API 密钥、密码、证书等。 Vault 为任何秘密提供统一的接口，同时提供严格的访问控制并记录详细的审计日志。
现在，这种方法非常适用于在服务器中运行的代码，但对于移动应用程序开发来说，唯一的优势是您没有将秘密硬编码在移动应用程序的源代码中，因此您不需要不要让它在你的 Git 存储库中泄露（前提是你没有忘记在 .gitignore 中有 .env），但你会在移动应用程序二进制文件中以普通字符串的形式获得秘密，这很容易使用静态二进制文件进行逆向工程分析，正如我在文章中描述的那样 How to Extract an API key from a Mobile App with Static Binary Analysis:
可用于逆向工程的开源工具范围很广，我们在本文中确实无法触及这个主题的表面，但我们将重点使用Mobile Security Framework(MobSF) 来演示如何逆向工程我们的移动应用程序的 APK。 MobSF 是一组开源工具，它们在一个有吸引力的仪表板中展示其结果，但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。
正如我在文章中所说，您甚至可以在 Linux 中使用strings 命令来提取它。
https://reactnative.dev/docs/security#storing-sensitive-info
请不要听从他们的建议，除非：
如果您必须拥有 API 密钥或机密才能从您的应用访问某些资源，那么最安全的处理方法是在您的应用和资源之间构建一个编排层。这可能是一个无服务器函数（例如，使用 AWS Lambda 或 Google Cloud Functions），它可以使用所需的 API 密钥或密钥转发请求。 API 使用者无法访问服务器端代码中的机密，就像您的应用代码中的机密一样。
为什么？那么您如何保护对该编排层的访问？根据他们的描述，它似乎没有受到保护，因此攻击者需要做的就是在他控制的设备中对您的移动应用程序执行 MitM 攻击，并了解该应用程序如何与该编排层通信，然后我们就可以做到在移动应用程序之外也是如此。最糟糕的是，这个编排层实际上是对世界开放的，因此任何人都可以做你害怕的事情：
我不希望每个知道端点并会发现 api 密钥的人都可以使用我的后端 API，例如 Postman 请求。
让我们看看除非位...
现在，如果您使用秘密保护对编排层的访问，那么您几乎可以回到零，但如果您的应用与多个后端通信，例如使用多个第三方 API，则使用反向代理（编排层）是我在文章Using a Reverse Proxy to Protect Third Party APIs 中描述的一个好方法：
在本文中，您将首先了解什么是第三方 API，以及为什么不应该直接从移动应用中访问它们。接下来，您将了解什么是反向代理，以及何时以及为何使用它来保护对移动应用中使用的第三方 API 的访问。
现在您可能想知道如何保护您的移动应用程序运行时访问反向代理的秘密？？？
在我上面链接的用于提取 API 密钥的文章中，您可能已经注意到我使用 repo android-hide-secrets 演示了一些不同的方法来将它们隐藏在二进制文件中，这是使用原生 C 代码的最有效的方法。虽然这使得通过静态二进制分析难以提取秘密，但它并没有为您提供任何针对运行时攻击的保护，例如可以使用检测框架执行的攻击，例如 Frida：
将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。
借助检测框架，您甚至可以利用 iOS 和 Android 操作系统提供的所有最先进的技术，以加密方式窃取存储在移动设备中的秘密，因为攻击者将挂钩返回秘密的函数未加密以便在请求中使用。
这很可怕，因为检测框架在运行时攻击移动应用程序的可能性无穷无尽，人们可能认为它注定无法在运行时保护代码，但游戏还没有结束，你仍然可以求助于移动应用程序App Attestation 概念，为此我建议您阅读this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是部分保护 API 服务器 em> 和 可能更好的解决方案。
移动应用证明概念可能是您正在寻找的这个问题的答案：
在这种情况下，我可以做些什么来保护我的后端 API？
始终请记住，安全性就是在您负担得起或法律要求的情况下添加尽可能多的防御层。这不是什么新鲜事，只要记住城堡的防御是如何由多层组成的。
在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
【讨论】：