如何确保API请求来自我们的移动(ios/android)应用程序？

Question

我们正在构建一个移动应用程序,并希望实现某种身份验证,以确保我们的应用程序只能访问API.该应用程序的用户是匿名的,没有登录,但我通过设备ID识别它们以维护设置等.

最简单的方法似乎是生成一个Guid/API密钥,我通过SSL发送每个请求.

令我担心的是,有大量空闲时间的恶意人员可能会下载应用程序,对其进行反编译以获取API密钥和JSON请求,然后尽可能地删除我的数据库.

SSL,API密钥,设备ID以及具有尽可能受限制的呼叫的API是否足够好？我应该采取不同的方法吗？我的恐惧是建立还是毫无根据？

Answer 1

不要在应用中嵌入单个API密钥.您的疑虑对恶意用户的影响是有效的.此外,您在当前设置中存在严重漏洞,您可能会让恶意API用户通过提供虚假UDID来更改其他用户的首选项.

相反,创建一个"注册"服务,该服务在设备上第一次启动应用程序时调用,该服务基于UDID生成并返回GUID.将GUID存储在设备本地用户首选项和服务器上.跟踪GUID并在服务器上的每个请求中将其与UDID匹配.

确保所有这些都通过SSL发生.

使用这种方法,没有嵌入的主API密钥被滥用.此外,您可以通过标记GUID/UDID组合将滥用用户列入黑名单,还可以消除现有的可能伪装现有注册设备的问题.但是,您无法阻止恶意注册尚未向您的服务注册的设备.这将始终是使用设备ID作为用户标识符的潜在危险.

有更好和更成熟的认证机制采取更好的方法,即.您应该看一下OAuth,JSessionID等.

此外,将来您不应使用UDID来识别您的用户,因为已弃用对其的访问权限.您可以通过在应用程序安装时在设备上创建自定义设备GUID并将其保存在本地用户首选项中,来模仿UDID以达到您的目的.

Answer 2

我们正在构建一个移动应用程序，并希望实现某种身份验证，以确保 API 仅由我们的应用程序访问。该应用程序的用户是匿名的，无需登录，但我确实通过设备 ID 来识别他们以维护设置等。

当涉及用户身份验证时，锁定 API 服务器以仅回复移动应用程序真实实例的请求的过程已经相当困难，但尝试对匿名用户执行此操作确实是一项艰巨的任务，让我们看看为什么。 。

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

首先，让我们首先澄清一个常见于任何级别的开发人员中的误解，即访问 API 服务器的人员和内容之间的差异。

我撰写了一系列有关 API 和移动安全的文章，并在文章《为什么您的移动应用程序需要 Api 密钥？》中 您可以详细阅读访问 API 服务器的人员和内容之间的区别，但我将在此摘录其中的主要内容：

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

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

您可以将谁视为API 服务器能够对数据进行身份验证和授权访问的用户，并将什么视为代表用户发出该请求的软件。

在您的用例中，一旦匿名，识别谁就变得更加困难，但无论哪种方式，您仍然必须识别代表其执行请求的用户，无论用户是否匿名，这似乎是几乎每个人都缺少的部分当尝试使用其移动应用程序的真实实例锁定 API 服务器时，似乎错过了。

逆向工程

让我担心的是，恶意人员有大量空闲时间可能会下载该应用程序，对其进行反编译以获取 API 密钥和 JSON 请求，然后尽可能地销毁我的数据库。

如今（2021 年）对应用程序进行逆向工程不需要大量空闲时间，也不需要太多技能，因为有很多开源工具可以帮助完成此任务，正如我在文章如何提取API中概述和演示的那样来自具有静态二进制分析的移动应用程序的密钥：

可用于逆向工程的开源工具种类繁多，在本文中我们确实无法触及这个主题的表面，但我们将重点关注使用移动安全框架（MobSF）来演示如何对我们的移动应用程序的 APK。MobSF 是开源工具的集合，它们在有吸引力的仪表板中展示其结果，但是 MobSF 和其他地方在幕后使用的相同工具可以单独使用以实现相同的结果。

你的问题

我的恐惧是有根据的还是毫无根据的？不，它们并非毫无根据，相反是有根据的。

SSL、API 密钥、设备 ID 和具有尽可能受限调用的 API 是否足够好？

在您阅读了访问您的 API 服务器的人员与对象之间的区别之后，我相信您已经获得了足够的洞察力，明白这不足以让 API 服务器以非常高的置信度识别正在执行请求的内容。

例如，可以通过 MitM 攻击来提取正在使用的 DeviceID，正如我在如何使用静态二进制分析从移动应用程序中提取 API 密钥一文中概述和演示了提取 API 密钥一样：

可用于逆向工程的开源工具种类繁多，在本文中我们确实无法触及这个主题的表面，但我们将重点关注使用移动安全框架（MobSF）来演示如何对我们的移动应用程序的 APK。MobSF 是开源工具的集合，它们在有吸引力的仪表板中展示其结果，但是 MobSF 和其他地方在幕后使用的相同工具可以单独使用以实现相同的结果。

可能的不同方法

我应该采取不同的方法吗？

安全性就是根据法律要求为每个用例添加尽可能多的防御层。

所以，是的，你应该并且我鼓励你阅读我在 Stack Overflow 中给出的其他回复，以了解如何强化 Api 服务器安全性，以及最终如何通过使用 Mobile 应用程序来使用移动应用程序的真实实例锁定 API 服务器应用程序证明概念将允许 API 服务器以非常高的置信度识别正在执行请求的内容：

例如，我建议您阅读我针对问题如何保护移动应用程序的 API REST？，特别是“强化和屏蔽移动应用程序” 、“保护 API 服务器安全”和“可能的更好解决方案”部分。

因此，除了您可能已经采取的措施来识别匿名用户之外，您还可以添加移动应用程序证明解决方案，以确保脚本无法使用真实且未经篡改的移动应用程序版本冒充匿名用户。

您想加倍努力吗？

在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。

对于APIS

OWASP API 安全性前 10 名

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

对于移动应用程序

OWASP 移动安全项目 - 十大风险

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

OWASP - 移动安全测试指南：

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