在 React-Native 应用程序中保护逆向工程师的 API 密钥
Ste*_*eve 3 security api-key mobile-application react-native
我最近阅读了很多关于将敏感信息保护到 React Native 应用程序中的帖子和文章。据我了解，你无法完全保护你的敏感信息，只会让黑客更难获取这些信息。
因此，从这个角度来看，我想知道从外部服务器（即 Rest API）获取这些敏感信息（即 API 密钥）是否会“更安全”。
我解释：
我了解 MitM 攻击，但是让我的移动应用程序调用我的 API 以通过 HTTPS 根据请求获取 API 密钥会更安全（也更灵活）吗？这样，应用程序二进制文件中就不会保留任何敏感信息。
为了确保 MitM 攻击的安全，我可以经常更改这些 API 密钥值，以便它们仅在短时间内保持有效。
我想听听任何人关于这样一个系统的优点和缺点。
API 误解
\n为了让您为我的回答做好准备，我将首先澄清一些关于公共/私有 API 以及谁与什么真正访问您的后端的常见误解。
\n公共和私有 API
\n我经常看到开发人员认为他们的 API 是私有的，因为他们没有相关文档，没有在任何地方宣传它，以及许多其他原因。
\n事实是，当您发布移动应用程序时，与其通信的所有 API 现在都属于公共域，如果此 API 没有适当的身份验证和授权机制，那么其背后的所有数据都可以被任何人访问。互联网对你的移动应用程序的工作方式进行逆向工程。即使 API 进行了身份验证，它们也可能容易受到错误实现的影响，并且根据OWASP API 安全十大漏洞列表，有些 API 完全缺乏授权机制或存在错误。
\nWHO 和 WHAT 之间的区别是访问 API 服务器
\n我撰写了一系列有关 API 和移动安全的文章，并在文章《为什么您的移动应用程序需要 Api 密钥？》中 您可以详细阅读访问 API 服务器的人员和内容之间的区别，但我将在此摘录其中的主要内容：
\n\n\n向 API 服务器发出请求的是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 等工具手动探查您的 API 服务器？
\n
\n\n我们可以通过多种方式（例如使用 OpenID Connect 或 OAUTH2 流）对移动应用程序的用户进行身份验证、授权和识别。
\n
因此，请考虑谁作为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并考虑代表用户发出该请求的软件是什么。
\nAPI密钥服务
\n\n\n我了解 MitM 攻击，但是让我的移动应用程序调用我的 API 以通过 HTTPS 根据请求获取 API 密钥会更安全（也更灵活）吗？这样，应用程序二进制文件中就不会保留任何敏感信息。
\n
虽然您的应用程序二进制文件中确实没有任何敏感信息，但您还没有解决问题。在我看来，您的暴露程度更高，因为您现在从公共且开放的 API 端点获取 API 密钥。
\n我说它是开放的，因为您没有任何保障来确保向它发出请求的确实是您的移动应用程序的真实且未经篡改的版本。
\n因此，现在攻击者所需要做的就是 MitM 攻击您的移动应用程序或对其进行反编译，以查看您从哪个 API 端点获取 API 密钥来发出请求，然后从其自动化脚本/机器人复制该过程，因此不会\您不再将它们硬编码到应用程序二进制文件中并不重要。
\nAPI 密钥轮换
\n\n\n为了确保 MitM 攻击的安全，我可以经常更改这些 API 密钥值，以便它们仅在短时间内保持有效。
\n
根据上述解释，在 API 密钥服务部分，您甚至可以将 API 密钥限制为仅用于攻击者仍会成功的单个请求，因为攻击者将能够查询 API 端点以获取API 密钥就好像他是后端所期望的那样，是您的移动应用程序的真实且未经篡改的版本。
\n因此，需要明确的是，我赞成 API 密钥轮换，但前提是您可以从安全的外部源将它们放入您的移动应用程序，但您的方法是开放的，可供互联网上的任何人访问。
\n\n\n我想听听任何人关于这样一个系统的优点和缺点。
\n
您所描述的系统不建议实施，因为如果没有保护，它只会发生一场安全灾难。使用 API 密钥来保护它，这只是回到了最初的问题，其缺点是您将想要远离黑客的敏感信息返回给移动设备。
\n最适合您的方法是使用反向代理来保护 API 密钥的私密性并防止他人窥探。
\n反向代理方法
\n\n\n因此，从这个角度来看，我想知道从外部服务器（即 Rest API）获取这些敏感信息（即 API 密钥）是否会“更安全”。
\n
您需要的是实现反向代理，该代理通常用于保护对第三方 API 和您自己的 API 的访问，方法是让移动应用程序将 API 请求委托给反向代理，而不是要求提供 API 密钥从移动应用程序内部制作它们。
\n反向代理方法将避免在移动应用程序中对多个 API 密钥进行编码，但您仍然需要一个 API 密钥来保护对反向代理的访问，因此您仍然容易受到 MitM 攻击以及移动应用程序的静态逆向工程。
\n现在的优势在于，您所有敏感的 API 密钥都是私有的，并且在您可以控制和采用所需的尽可能多的安全措施的环境中，以确保请求确实来自，即您的移动应用程序的真实且未经篡改的版本。
\n通过阅读我撰写的文章使用反向代理来保护第三方 API，了解有关使用反向代理的更多信息：
\n\n\n在本文中，您将首先了解什么是第三方 API，以及为什么您不应该\xe2\x80\x99 直接从移动应用程序中访问它们。接下来，您将了解什么是反向代理，然后了解何时以及为何应使用它来保护对移动应用程序中使用的第三方 API 的访问。
\n\n
虽然本文重点讨论第三方 API，但该原则也适用于您自己的 API。
\n防止中间人攻击
\n当在移动应用程序中实施证书固定以保护 https 通道时，可以更好地防止 API 请求上的敏感数据被提取。
\n我建议您阅读我Preventing MitM Attacks在另一个问题的答案中给出的部分，您将在其中了解如何实现静态证书固定以及如何绕过它。
尽管可以绕过证书锁定，但我仍然强烈建议实施它，因为它减少了移动应用程序上的攻击面。
\n可能更好的解决方案
\n我建议您阅读我针对“How to secure an API REST for mobile app?”问题给出的答案。，特别是“强化和屏蔽移动应用程序” 、“保护 API 服务器安全”和“可能的更好解决方案”部分。
\n该解决方案将使用移动应用程序证明解决方案，该解决方案将使您的后端高度确信该请求来自其期望的内容，即移动应用程序的真实且未经篡改的版本。
\n您想加倍努力吗？
\n在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
\n对于APIS
\n\n\n\nOWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建并维护十大 API 安全风险文档，以及创建或评估 API 时最佳实践的文档门户。
\n
对于移动应用程序
\n\n\n\n\nOWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
\n
\n\n移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
\n
| 归档时间： |
|
| 查看次数： |
2455 次 |
| 最近记录： |