react-native 应用程序中的敏感数据如何安全 代码混淆及其重要性WHO 和 WHAT 访问 API 服务器的区别一种可能的幼稚方法可能更好的解决方案对于 APIS对于移动应用

如何解决react-native 应用程序中的敏感数据如何安全 代码混淆及其重要性WHO 和 WHAT 访问 API 服务器的区别一种可能的幼稚方法可能更好的解决方案对于 APIS对于移动应用

在我的应用程序中，我与 keycloak 连接以获取 API 密钥和安全存储以保存用户数据。

我如何确保安全：

• 需要连接到keycloak的秘密ID
• 访问安全存储的密钥

我阅读了不同的文章，但没有找到正确保护这些数据的方法。来自 APK 的简单还原工程显示了秘密数据。

混淆代码是可能的，但这不是一个严肃的解决方案，这对性能有很大影响。

解决方法

将一个问题与另一个问题交换

在我的应用程序中，我与 keycloak 连接以获取 API 密钥和安全存储以保存用户数据。

因此，使用 KeyCloak 在运行时检索 API 密钥，以免在移动应用程序中对其进行硬编码，只是将问题从保护 API 密钥转移到保护 KeyCloak 机密。

从移动应用中提取秘密

我如何确保安全：

• 需要连接到keycloak的秘密ID
• 访问安全存储的密钥

残酷的事实是，您无法正确保护它们，因为您在移动应用程序版本中发布的任何秘密都必须被视为属于公共领域，因为它在客户端，因此任何人都可以花时间/she 希望通过静态或动态分析对移动应用进行逆向工程以提取它。

您可以使用 JNI/NDK 在 Natice C 代码中隐藏秘密，正如我在文章 How to Extract an API key from a Mobile App with Static Binary Analysis 中所展示的：

可用于逆向工程的开源工具范围很广，我们在本文中确实无法触及该主题的皮毛，但我们将重点介绍如何使用 Mobile Security Framework(MobSF) 来演示如何逆向工程设计我们的移动应用程序的 APK。 MobSF 是一个开源工具的集合，它们在一个有吸引力的仪表板中展示他们的结果，但是在 MobSF 和其他地方使用的相同工具可以单独使用以获得相同的结果。

现在，由于隐藏在本机 C 代码中的秘密，提取它会很耗时，但并非不可能。因此，如果您无法通过静态逆向工程轻松做到这一点，那么您可以使用中间人攻击来做到这一点，如我在文章 Steal that Api Key with a Man in the Middle Attack 中所示：

为了帮助演示如何窃取 API 密钥，我在 Github 中构建并发布了适用于 Android 的 Currency Converter Demo 应用程序，它使用了我们在早期 {{} 中使用的相同 JNI/NDK 技术3}} 应用到 Android Hide Secrets。

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

你明白了吗？您可以使用静态二进制分析使提取变得非常困难，但是攻击者只需要使用像 mitmproxy 这样的工具来拦截流量并在请求的标头中查找 API 密钥即可。

您可以尝试保护您的移动应用免受中间人攻击，我在我的文章 hide the API key 中举例说明：

为了演示如何使用证书锁定来保护您的移动应用和 API 服务器之间的 https 流量，我们将使用我在上一篇文章中使用的相同 Securing HTTPS with Certificate Pinning 移动应用。

在本文中，我们将了解什么是证书锁定、何时使用它、如何在 Android 应用中实现它以及它如何防止中间人攻击。

但是，您需要注意，您也可以绕过固定，正如我在下一篇文章 Currency Converter Demo 中展示的那样：

为了演示如何绕过证书锁定，我们将使用与上一篇文章中使用的相同的货币转换器演示移动应用程序。

在本文中，您将学习如何重新打包移动应用以使其信任自定义 ssl 证书。这将允许我们绕过证书锁定。

攻击者的其他替代方法是使用检测框架挂钩从密钥库或 KeyCloak 服务器返回秘密或 API 密钥的代码。用于此类攻击的流行工具框架是 Bypass Certificate Pinning：

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

因此，当代码没有被混淆时，使用 Frida 来连接代码会更容易，因为通过使用一些可猜测的函数名称搜索代码很容易找到执行它的函数，或者只是求助在 IDE 的帮助下遵循代码流程。

代码混淆及其重要性

混淆代码是可能的，但这不是一个严肃的解决方案，这对性能有很大影响。

是的，您说得对，代码混淆不会隐藏秘密，只会使逻辑流程难以理解。

代码混淆应该仍然在您的移动应用安全加固列表中，并且一旦用作Frida，通过收缩代码和资源，使用 R8 混淆和优化您的应用，那么您将不会有较慢的应用程序只是因为代码被混淆了，但是你将有一个更难通过代码遵循逻辑的应用程序，因此攻击者在代码周围寻找以挂钩检测框架将有更多耗时的任务，有时不要说它令人沮丧。

保护移动应用程序中的秘密

我阅读了不同的文章，但没有找到正确保护这些数据的方法。来自 APK 的简单还原工程显示了秘密数据。

是的，你找不到，因为这不是一个微不足道的问题，你只能让它变得困难，但并非不可能。

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

在深入探讨解决您的问题的可能方法之前，我想首先澄清一个我在任何资历的开发人员中发现的误解，即谁和之间的区别什么正在访问 API 服务器。

我写了一系列关于 API 和移动安全的文章，在文章Google recommends中，您可以详细阅读谁和什么之间的区别访问您的 API 服务器，但我将在此处提取主要内容：

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

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

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

既然您对它们之间的区别有了更深入的了解，那么您就可以在为您的用例决定要采用的方法时在安全性和权衡方面做出更明智的决定。

一种可能的幼稚方法

• 隐藏您的 API 密钥，或者您是否更喜欢本机 C 代码中的 KeyCloak 秘密，正如我在上面链接的文章中所展示的那样，该文章引用了此 Why Does Your Mobile App Need An Api Key?。这使得静态逆向工程更难破解秘密。
• 按照 Google 说明缩减代码和资源、混淆和优化您的应用。这使得很难找到挂钩 Frida 的代码。
• 实施证书固定。这使得执行中间人攻击变得更加困难。

我称之为幼稚的方法，因为我在我链接的系列文章中已经展示过它可以被绕过，但它提高了执行此操作所需的技能和时间的标准。

可能更好的解决方案

因此，您的主要目标似乎是保护 API 密钥，您需要将其用作通过后端 API 服务器识别您的移动应用程序的方式，也就是使用真实和未篡改的版本锁定后端 API 服务器您的移动应用程序，这将允许服务器仅响应来自您上传到 Google Play 商店的同一二进制文件的请求，那么您可能需要查看移动应用程序证明概念，为此我建议您阅读Github repo我提出的问题如何为移动应用程序保护 API REST？，尤其是保护 API 服务器 和可能更好的解决方案。

简而言之，移动应用证明解决方案的作用是在运行时保证您的移动应用没有被篡改，没有在有根设备上运行，没有被 xPosed 或 Frida 等框架所检测，而不是被中间人攻击，这是通过在后台运行 SDK 来实现的。在云端运行的服务会挑战应用，并根据响应证明移动应用和设备运行的完整性，因此 SDK 永远不会对任何决定负责。

你想走得更远吗？

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

对于 APIS

this answer

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

对于移动应用

OWASP API Security Top 10

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

OWASP Mobile Security Project - Top 10 risks：

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