我正在构建一个利用OpenAIAPI的应用程序
它们为我提供了一个API令牌，我用它从我的Android移动应用程序(原生react )进行API调用
我知道将此API令牌存储在移动客户端上是一种糟糕的做法，因为攻击者可能会将其保留并使用我的配额和金钱.
我有什么 Select ？简单的解决方案是构建一个后端，但我不想开始实现所有原始的API方法，我只是更喜欢直接从客户端使用它.
我试图以一种无法找到的方式存储令牌，但找不到方法.
我正在构建一个利用OpenAIAPI的应用程序
它们为我提供了一个API令牌，我用它从我的Android移动应用程序(原生react )进行API调用
我知道将此API令牌存储在移动客户端上是一种糟糕的做法，因为攻击者可能会将其保留并使用我的配额和金钱.
我有什么 Select ？简单的解决方案是构建一个后端，但我不想开始实现所有原始的API方法，我只是更喜欢直接从客户端使用它.
我试图以一种无法找到的方式存储令牌，但找不到方法.
它们为我提供了一个API令牌，我用它从我的Android移动应用程序(原生react )进行API调用
我知道将此API令牌存储在移动客户端上是一种糟糕的做法，因为攻击者可能会将其保留并使用我的配额和金钱.
是的，这确实是一种非常糟糕的做法，但至少你意识到了风险，虽然很多人使用这种方法时并没有意识到攻击者窃取这些机密(Api令牌、API密钥，无论你怎么称呼它们)是多么容易.
在我写的一系列关于移动API安全的文章中，我展示了使用静态分析和MITM攻击是多么容易做到这一点:
How to Extract an API key from a Mobile App with Static Binary Analysis:
可用于反向工程的开源工具范围很广，在本文中我们确实无法触及这个主题的皮毛，但我们将重点使用Mobile Security Framework(MobSF)来演示如何对我们的移动应用程序的APK进行反向工程.MobSF是一组开源工具，它们将结果显示在一个漂亮的仪表板中，但在MobSF和其他地方幕后使用的相同工具可以单独使用，以实现相同的结果.
在本文中，我们将使用Android Hide Secrets研究库，这是一个虚拟的移动应用程序，使用几种不同的技术隐藏了API密钥.
一些攻击者更喜欢直接进行MITM攻击，因为他们将了解App如何与API后台通信，并提取所用的秘密，以及他们发出请求和解析响应所需的蓝图.
Steal that Api Key with a Man in the Middle Attack:
为了帮助演示如何窃取API密钥，我在Github中构建并发布了适用于Android的Currency Converter Demo应用程序，它使用的JNI/NDK技术与我们在之前的Android Hide Secrets应用程序hide the API key中使用的技术相同.
因此，在本文中，您将学习如何设置和运行MITM攻击来拦截您控制的移动设备中的HTTPS流量，以便您可以窃取API密钥.最后，您将从高层次上了解如何减轻MITM攻击.
简单的解决方案是构建一个后端，但我不想开始实现所有原始的API方法，我只是更喜欢直接从客户端使用它.
你不需要，你只需要你的后端代理你在你的移动应用上使用的第三方API的请求，在你的情况下，似乎只有OpenAPI.
例如，当您的移动应用程序需要向openapi.io/some/resource发出请求时，它会向your-reverse-proxy.com/some/resource发出请求，然后your-reverse-proxy.com/some/resource将获取/some/resource部分并构建对OpenAPI openapi.io/some/resource的请求，向其添加API令牌头，现在它安全地存储在您的反向代理服务器中.
Using a 反向代理 to Protect Third Party APIs个
在这篇文章中，你将首先了解什么是第三方API，以及为什么你不应该直接从你的移动应用程序中访问它们.接下来，您将了解什么是反向代理，以及何时以及为什么应该使用它来保护对移动应用程序中使用的第三方API的访问.
本文中反复出现的一个主题是建议不要直接从移动应用程序访问第三方API.正如我们已经讨论过的，一旦你的移动应用程序发布，其中的任何秘密都会公之于众，因此攻击者可以利用它来代表你使用.如果你不小心，你就会成为买单的人，或者发现你的空闲层资源已经被别人耗尽了.
这种方法的缺点是，您仍然有一个需要保护的API密钥，即访问反向代理的密钥，但至少您没有expose 您的OpenApi秘密，并且您可以使用几种机制来限制请求并保护对反向代理的访问，以确保只响应来自移动应用程序的真正和未经修改的实例的请求.
你可以设计或使用现成的机制来及时将秘密传递给你的移动应用程序，这些秘密被要求在向OpenAPI发出的API请求中使用，但你需要确保这些秘密只传递给你的移动应用程序的真正和未经修改的实例，这些实例没有受到MITM攻击，在运行时被Frida等工具篡改/篡改，否则你的秘密将很容易通过挂钩到将它们添加到API请求报头的函数或通过MITM攻击拦截请求来提取，即使通信通道使用证书固定保护它也是如此.因为在攻击者控制的设备中绕过并不是那么难.
在问题Storing Api Keys Securely in Flutter or Sending Payment Details to my Server?的my reply中，我将更详细地介绍运行时机密保护方法.
在回答任何安全问题时，我总是喜欢参考OWASP基金会的出色工作.
OWASP API安全项目旨在通过强调不安全API中的潜在风险，并说明如何缓解这些风险，为软件开发人员和安全判断人员提供价值.为了促进这一目标，OWASP API安全项目将创建和维护十大API安全风险文档，以及在创建或判断API时用于最佳实践的文档门户.
OWASP Mobile Security Project - Top 10 risks个
OWASP移动安全项目是一个集中式资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源.通过该项目，我们的目标是对移动安全风险进行分类，并提供发展控制，以减少它们的影响或被利用的可能性.
OWASP - Mobile Security Testing Guide:
《移动安全测试指南》(MSTG)是一本针对移动应用安全开发、测试和逆向工程的综合手册.