我们正在构建一个移动应用，并希望实施某种身份验证，以确保 API 只能由我们的应用访问。该应用程序的用户是匿名的，没有登录，尽管我确实通过设备 ID 识别他们以维护设置等。
最简单的方法似乎是生成一个 Guid / API 密钥，我通过 SSL 随每个请求发送该密钥。
让我担心的是，有很多空闲时间的恶意人员可能会下载该应用程序，对其进行反编译以获取 API 密钥和 JSON 请求，然后尽可能地丢弃我的数据库。
SSL、API 密钥、设备 ID 和具有尽可能受限调用的 API 是否足够好？我应该采取不同的方法吗？我的恐惧是有根据还是毫无根据？
【问题讨论】：
请勿在应用中嵌入单个 API 密钥。您对恶意用户的影响的担忧是正确的。此外，您当前的设置中存在严重漏洞，您可以让恶意 API 用户通过提供虚假 UDID 来更改其他用户的偏好。
相反，创建一个“注册”服务，该服务在应用程序首次启动时在设备上生成并返回基于 UDID 的 GUID。将 GUID 存储在您的设备本地用户首选项和服务器上。跟踪 GUID 并将其与服务器上每个请求的 UDID 匹配。
确保所有这些都通过 SSL 进行。
使用这种方法，不会滥用嵌入式主 API 密钥。此外，您可以通过标记 GUID/UDID 组合将滥用用户列入黑名单，还可以消除现有注册设备的潜在伪装问题。但是，您无法阻止恶意注册尚未向您的服务注册的设备。这将始终是使用设备 ID 作为用户标识符的潜在危险。
还有更好和更成熟的身份验证机制采用更好的方法，即。您应该查看的 OAuth、JSessionID 等。
此外，将来您不应使用 UDID 来识别您的用户，因为对它的访问已被弃用。您可以通过在应用程序安装时在设备上创建自定义设备 GUID 并将其保存在本地用户首选项中来模仿 UDID。
【讨论】：
我们正在构建一个移动应用，并希望实施某种身份验证，以确保 API 只能由我们的应用访问。该应用程序的用户是匿名的，没有登录，但我确实通过设备 ID 识别他们以维护设置等。
当涉及到用户身份验证时，锁定 API 服务器以仅回复移动应用程序的真实实例的请求的过程已经相当困难，但尝试对匿名用户执行此操作确实是一项艰巨的任务，让我们看看为什么……
首先，让我们首先澄清一个通常在任何资历的开发人员中发现的误解，即谁和什么访问 API 服务器之间的区别。
我写了一系列关于 API 和移动安全的文章，在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 谁 和 what 访问你的API 服务器，但我将在这里提取它的主要内容：
what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
您可以将 谁 视为 API 服务器能够对数据进行身份验证和授权访问的用户，并将 what 视为软件制作代表用户提出该请求。
在您的用例中，一旦他们是匿名的，识别 谁 变得更加困难，但无论哪种方式，您仍然必须识别 什么 代表它执行请求，是用户是否匿名，这似乎是几乎每个人在尝试使用其移动应用程序的真实实例锁定 API 服务器时都错过的部分。
让我担心的是，有很多空闲时间的恶意人员可能会下载该应用程序，对其进行反编译以获取 API 密钥和 JSON 请求，然后尽可能地丢弃我的数据库。
现在（2021 年）对应用程序进行逆向工程不需要很多空闲时间，也不需要很多技能，因为正如我在我的文章 @987654322 中概述和演示的那样，存在许多开源工具来帮助完成这项任务@：
可用于逆向工程的开源工具种类繁多，我们在本文中确实无法触及这个主题的表面，而是将重点使用Mobile Security Framework(MobSF) 来演示如何逆向工程我们的移动应用程序的 APK。 MobSF 是一组开源工具，它们在一个有吸引力的仪表板中展示其结果，但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。
我的恐惧是有根据的还是毫无根据的？ 不，它们并非毫无根据，相反是有根据的。
SSL、API 密钥、设备 ID 和具有尽可能受限调用的 API 是否足够好？
在您阅读了 谁* 与 what 正在访问您的 API 服务器之间的区别之后，我相信您获得了足够的洞察力来理解这对于API 服务器以非常高的可信度识别什么正在执行请求。
例如，正如我在我的文章How to Extract an API key from a Mobile App with Static Binary Analysis 中概述和演示用于提取 API 密钥的那样，可以通过中间人攻击来提取正在使用的 DeviceID：
可用于逆向工程的开源工具范围很广，我们在本文中确实无法触及这个主题的表面，但我们将重点使用Mobile Security Framework(MobSF) 来演示如何逆向工程我们的移动应用程序的 APK。 MobSF 是一组开源工具，它们在一个有吸引力的仪表板中展示其结果，但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。
我应该采取不同的方法吗？
安全就是为每个用例添加尽可能多的防御层和法律要求。
所以，是的，您应该并且我鼓励您阅读我在 Stack Overflow 中给出的其他回复，以了解如何加强 Api 服务器的安全性，以及最终如何通过您的移动应用程序的真实实例锁定 API 服务器采用移动应用证明概念，这将允许 API 服务器以非常高的可信度识别 什么 正在执行请求：
例如，我建议您阅读 this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是强化和屏蔽移动应用程序部分、保护 API 服务器和可能的更好解决方案。
因此，除了您可能已经在识别匿名用户之外，您还可以添加移动应用证明解决方案，以确保脚本无法使用真实且未篡改的版本伪装成匿名用户您的移动应用。
在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
【讨论】：