如何保护公共 API（无凭据）不被利用？

Posted 2023-03-21

【中文标题】如何保护公共 API（无凭据）不被利用？

【英文标题】：How to protect public APIs (no credentials) from being exploited?

【发布时间】：2021-12-24 02:41:31

【问题描述】：

这是一个更笼统的问题，但是推荐的保护注册过程中使用的 API 的方法是什么？假设有这些公共 API（无需用户凭据，只需 API KEY）；

find_person（有关尝试注册的人的数据），如果一个人已经存在或不存在则返回（不需要用户凭据并且不返回任何敏感信息）。 create_person（有关尝试注册的人的数据），将此人创建到系统中（无需用户凭据）

我们可以让“匿名”用户拥有短期 JWT 令牌吗？例如，SPA Web 应用程序或移动应用程序如何安全地获取“每会话”匿名用户？ 验证码在这种情况下真的有用吗？

我们已经在考虑：

每个应用程序（不是每个会话）的 API KEY 速率限制 用于保护 API 的 DDoS 服务

任何帮助将不胜感激。

谢谢

【问题讨论】：

“没有返回有意义的信息”听起来像是我知道的很多 API。但您的意思是“没有敏感信息”吗？

哈哈哈......很棒。修复。谢谢...不知何故这也是明智的...大声笑

你想阻止什么事情发生？

更新您的问题以解决特定问题可能会有所帮助，因为现在的框架方式更像是：“公共 API 的安全相关实践的全部内容是什么”，很难具体回答。

谢谢，@Evert，我想到了两个场景：1）人们使用这个 API 来利用我们的服务，也许通过蛮力发现我们的客户是谁......不太可能，但如果可以通过最佳实践来预防，为什么不呢？ 2）在我们的系统中创建许多假人

【参考方案1】：

短期 JWT 令牌

我们可以让“匿名”用户拥有短期 JWT 令牌吗？

是的，您可以并且建议您甚至为已登录的用户执行此操作。见 Auth0 博客What Are Refresh Tokens and How to Use Them Securely：

本文将探讨 OAuth 2.0 定义的刷新令牌的概念。我们将了解它们如何与其他令牌类型进行比较，以及它们如何让我们平衡安全性、可用性和隐私性。

为匿名用户或登录用户使用令牌的问题在于，他们只能识别谁在请求中，而不是什么在执行请求。

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

我写了一系列关于 API 和移动安全的文章，在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 谁 和 what 访问你的API 服务器，但我将在这里提取它的主要内容：

what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？

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

因此，考虑谁作为用户（匿名或登录）您的 API 服务器将能够验证和授权对数据的访问，并考虑什么 作为代表用户提出请求的软件。

您可能的解决方案

我们已经在考虑：

每个应用程序（不是每个会话）的 API KEY 速率限制 用于保护 API 的 DDoS 服务

这是任何 API 都应该实施的基本安全措施，但是当 API 服务器高度确信请求确实来自它所期望的什么时，它们将达不到要求，a您的应用的正版和未篡改版本。

你可以在我的文章The Top 6 Mobile API Protection Techniques - Are They Enough?阅读更多内容：

在本文中，我们将探讨用于保护 API 的最常用技术，包括使用 HTTPS 保护移动应用程序和 API 之间的通信通道的重要性，如何使用 API 密钥来识别每个应用程序上的移动应用程序API 请求，用户代理、验证码和 IP 地址如何用于 bot 缓解，以及最终用户身份验证对移动安全和 API 安全的重要性。我们将讨论这些技术中的每一个，并讨论它们如何影响业务风险状况，即它们是多么容易绕过。

读者将理解为什么当今常用的移动 API 保护技术非常幼稚，不适合保护数字业务免受 API 滥用。 API 滥用的各种形式更为普遍，大多数企业都意识到，因此采用正确的技术来维持收入和品牌声誉非常重要。

其他可能的解决方案

例如，SPA Web 应用程序或移动应用程序如何安全地获取“每会话”匿名用户？

对于网络应用，只需使用浏览器上的开发者工具，就可以很容易地对它们进行内省并查看 API 请求及其响应。

对于移动应用程序来说，它需要更多的工作，但是存在大量的开源工具可以使其变得简单，并且在某些情况下微不足道，甚至非开发人员也可以做到这一点，从而使保护 API 服务器的任务变得非常困难，但并非不可能。

因此，网络和移动设备的工作方式完全不同，保护它们的方法也会有所不同。

对于网络应用程序

验证码在这种情况下真的有用吗？

Captcha 会给您一个分数，告诉您请求中的谁可能是真人。在最好的情况下，它不能高度自信地保证什么正在执行请求确实是什么您的API服务器所期望的，您的网络的真实且未篡改的版本或移动应用。

要学习一些有用的技术来帮助您的 API 后端尝试仅响应来自 what 您所期望的真正网络应用程序的请求，您可以阅读my answer 问题保护 api 数据免受应用外调用的影响，尤其是专门用于保护 API 服务器的部分。

对于移动应用

这是一个比较笼统的问题，但是推荐的保护注册过程中使用的 API 的方法是什么？

尽管不是专门针对注册过程，但我建议您阅读 this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是强化和保护移动应用程序、保护 API 服务器和可能的更好解决方案。

根据该答案，可以采用的更好方法是使用移动应用程序证明解决方案，该解决方案将使 API 服务器知道只接收来自它所期望的 什么 的请求，一个真实且未篡改的版本您的移动应用程序。

你想加倍努力吗？

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

对于 APIS

OWASP API Security Top 10

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

对于移动应用

OWASP Mobile Security Project - Top 10 risks

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

OWASP - Mobile Security Testing Guide:

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

对于网络应用程序

The Web Security Testing Guide:

OWASP Web 安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架和描述测试最常见 Web 应用程序和 Web 服务安全问题的技术的“低级”渗透测试指南。