您如何在移动应用程序中保护项目范围的 API 密钥 对于 APIS对于移动应用

如何解决您如何在移动应用程序中保护项目范围的 API 密钥 对于 APIS对于移动应用

关于 S.E 的许多其他问题都在问同样的问题。

一些评分最高的问题以基于意见的形式结束，例如Best practice for storing and protecting private API keys in applications

此处发布了一些最佳做法： https://support.google.com/googleapi/answer/6310037?hl=en

总结：

1. 不要直接在代码中嵌入 API 密钥
2. 不要将 API 密钥存储在应用程序源代码树中的文件中
3. 限制您的 API 密钥仅由 IP 地址、引荐来源网址和移动设备使用 需要它们的应用
   （如果您不知道在移动应用上运行的客户端将从哪里使用密钥进行连接，则这是不可能的）
4. 限制您的 API 密钥仅可用于某些 API
   （如果您不是 API 的创建者，这是不可能的）
5. 删除不需要的 API 密钥
6. 定期重新生成您的 API 密钥
   （Nr 5 和 6 对于移动应用程序也不实用，除非您强制用户每隔几天更新一次应用程序。）

如果我们关注这些最佳实践，它会给需要访问例如股票交易 API 的移动应用程序提供不要但没有明确的注意事项。

依靠混淆器（例如 ProGuard 或 dexguard）不会使上述 #1 或 #2 无效，那么如何解决这个问题？

解决方法

TL/DR：你没有。

长答案：

随应用程序分发的任何密钥都可以由应用程序读取以供使用。因此，该应用程序具有读取密钥所需的一切，即使它被加密或混淆。攻击者可以使用应用程序使用的相同技术来获取密钥。

同样，从外部来源获取密钥并不能保护它。攻击者可以再次使用相同的渠道获取密钥的副本。

除了攻击应用获取密钥的渠道（从包内的加密存储或外部来源），攻击者还可以从应用的内存或通过拦截网络传输来获取它。

唯一安全的解决方案是永远不要在最终用户设备上拥有密钥的副本。

密钥应保存在安全良好的服务器上，该服务器将充当用户设备和最终服务之间的中间人。客户端设备对终端服务的任何请求都需要通过此服务器进行路由。

具有“全局项目密钥”的服务器应代表最终用户向最终服务发出请求，并将结果（而不是任何密钥）返回给客户端。对于要使用此服务器的客户端，必须使用每个用户的身份验证会话。在将请求转发到最终服务之前，服务器必须为每个请求验证此会话。

总结：

在客户端和最终服务之间使用安全服务器代表客户端使用全局密钥发出请求。

编辑： 旁注：需要区分每个用户的密钥和项目范围的密钥。在该用户的设备上保留特定于某个人的密钥是可以接受的。

,

隐藏该 API 密钥

依靠混淆器（例如 ProGuard 或 DexGuard）不会使上述 #1 或 #2 无效，那么如何解决这个问题？

虽然 ProGuard 或 DexGuard 不能解决问题，但通过重命名 API 密钥关联的名称，它们会使问题变得更难，而如果 API 密钥隐藏在本机 C 代码中，则不会关联它的字符串在执行静态二进制分析时提供任何参考，因此更难以提取，正如我在我的文章 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 密钥的虚拟移动应用程序。

虽然此解决方案使通过二进制分析提取 API 密钥变得非常困难，但并非不可能，但存在更简单的方法来提取 API 密钥，例如在我的文章中进行演示时进行中间人攻击{{ 3}}：

为了帮助演示如何窃取 API 密钥，我在 Github 中构建并发布了适用于 Android 的 Steal that Api Key with a Man in the Middle Attack 应用程序，它使用了我们在早期 {{} 中使用的相同 Currency Converter Demo 技术3}} 应用到 JNI/NDK。

因此，在本文中，您将学习如何设置和运行中间人攻击来拦截您控制的移动设备中的 https 流量，以便您可以窃取 API 密钥。最后，您将在高层次上看到如何缓解 MitM 攻击。

检测框架还可以与中间人攻击结合使用，以在移动应用使用时绕过证书锁定。一种流行的是Android Hide Secrets：

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

反向代理服务器

如果我们关注这些最佳实践，它会给需要访问例如股票交易 API 的移动应用程序提供不要但没有明确的注意事项。

解决在移动应用程序代码中存储 API 密钥问题的另一种常见方法是将访问第三方 API 的责任委托给反向代理，就像我在文章中所写的那样 hide the API key：

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

现在，这只是将问题从保护第三方服务的 API 密钥（如股票交易 API）转移到保护 API 密钥或用于访问反向代理的任何其他秘密/标识符，但具有以下优势您现在可以控制如何访问第三方 API，同时将访问它的 API 密钥保持在移动应用攻击者无法触及的地方。

使用用户身份验证来保护对反向代理的访问会限制攻击的范围，但不会消除它，因为反向代理服务器需要能够区分谁和什么正在执行请求，根据我的经验，我看到任何资历的开发人员通常都没有意识到这种差异或对此有误解。

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

我写了一系列关于 API 和移动安全的文章，在文章Frida中，您可以详细阅读谁和什么之间的区别访问您的后端，无论是 API 服务器还是反向代理服务器。我将在这里提取主要内容：

什么是向 API 服务器发出请求的东西。它真的是您移动应用的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 等工具手动访问您的 API 服务器？

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

因此，请考虑将谁作为反向代理服务器将能够对第三方服务（在您的示例中为股票交易 API）进行身份验证和授权访问的用户，并考虑什么代表用户提出请求的软件。

强化反向代理服务器

如果我们关注这些最佳实践，它会给需要访问例如股票交易 API 的移动应用程序提供不要但没有明确的注意事项。

反向代理服务器可以配备用户行为分析 (UBA) 解决方案，使其能够区分谁与什么正在执行请求，但是这将尽最大努力完成，基于人工智能算法使用的历史数据来评估是人类或不执行请求的概率，也就是谁。

虽然 UBA 解决方案将显着减少攻击面，但它仍然是一种否定识别模型，因为会出现漏报和漏报，并且需要持续监控算法使用的策略/规则以达到最佳平衡在不阻止太多合法用户和不让太多攻击通过之间。

通过采用我在 Using a Reverse Proxy to Protect Third Party APIs 中推荐的移动应用证明概念，可以使用积极的识别模型代替如何保护移动应用的 API REST？ ，在一个可能的更好的解决方案部分。

因此，简而言之，Mobile App Attestion 可以说是一种能够以非常高的置信度锁定反向代理服务器与移动应用程序的解决方案，因为反向代理服务器将现在只能接受来自预期内容的请求，也就是移动应用的真实和未篡改版本。

你想走得更远吗？

在回答安全问题时，我总是喜欢引用 OWASP 基金会的优秀作品。

对于 APIS

Why Does Your Mobile App Need An Api Key?

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

对于移动应用

this answer

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

OWASP API Security Top 10：

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