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