未经授权的 API 调用 - 安全且仅允许注册的前端应用程序

Posted 2023-03-15

【中文标题】未经授权的 API 调用 - 安全且仅允许注册的前端应用程序

【英文标题】：Unauthorized API Calls - Secure and allow only registered Frontend app

【发布时间】：2020-06-15 00:58:21

【问题描述】：

我在 Laravel 中有后端 api 并使用 Laravel Passport(OAuth2)。我看到 OAuth2 非常酷，可以保护我的身份验证请求（在 laravel 中使用 api 中间件），并且只允许授权用户访问。

但我可以访问后端 api 以进行未经授权的使用，例如

路由： (/register) 或 (/login) 没有任何 api 密钥。大多数攻击者会在网络选项卡中看到此 api 调用，并可以发送 DDOS 攻击。由于 Laravel Passport 内置了速率限制，我仍然不希望人们访问我的后端 api，除非我手动允许它。

我想要什么：

我有两个前端应用程序。

android 原生移动应用。 Nuxt SPA 前端应用

我的 API 应该只能在这些前端工作。其他邮递员或浏览器请求不应通过，并且可能应显示不受支持的平台 json msg。

【问题讨论】：

我的建议是使用 lumen 而不是 laravel。 auth 脚手架和一堆其他不错的内置功能可能对您没有用，只会减慢速度。 Lumen 是仅 API 应用的最佳选择。

不，我也打算用它创建一个后端管理面板。所以，现在它变得有用了。 :)

【参考方案1】：

OAUTH 令牌真的足以保护您的后端吗？

我看到 OAuth2 非常酷，可以保护我的身份验证请求（在 laravel 中使用 api 中间件），并且只允许授权用户访问。

它允许访问提供有效 OAuth 令牌的任何请求，而不仅仅是授权用户。这是开发人员常见的误解，因为 OAuth 令牌仅代表请求中的谁，而不是发出请求的什么，我在@中更详细地讨论了这一点987654321@，您可以在这里阅读：

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

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

本文是在移动应用程序的上下文中，但在了解 谁 和 what 之间的区别方面，mobile app 和 web app 的概念是相同的 正在向后端服务器发出请求。

未经授权使用后端

但我可以访问后端 api 以进行未经授权的使用，例如

我希望现在您已经意识到，不仅您通往/register 和/login 的路线有被滥用的危险，因为目前您只知道谁在制造请求，而不是是什么提出的。

路由：(/register) 或 (/login) 没有任何 api 密钥。

即使您在此路由上拥有 API 密钥，也无法防止其被滥用于撞库攻击。

为什么你会问？

在网络应用程序中，提取 API 密钥所需的只是点击 F12 打开开发者工具选项卡并搜索它，或查看页面源代码。

您现在可能会想，哦，但在我的移动应用程序中这是不可能的，因为它是二进制文件，而且我什至使用了混淆。尽管稍微困难一点并不难，因为有很多开源工具可以帮助完成这项任务。

逆向工程

您可以使用MobSF 之类的工具对任何移动应用二进制文件进行逆向工程，并从中提取 API 密钥或任何秘密。我写了一篇文章How to Extract an API Key from a Mobile App by Static Binary Analysis，您可以按照它的实际示例进行操作，并通过 Github 的 Android Hide Secrets 存储库向您展示了在移动应用程序中隐藏 API 密钥的几种技术。

MobSF:

Mobile Security Framework (MobSF) 是一种自动化的一体化移动应用程序 (Android/ios/Windows) 渗透测试、恶意软件分析和安全评估框架，能够执行静态和动态分析。

如果您无法通过静态分析提取 API 密钥，则可以使用开源工具进行动态分析，例如 Frida：

将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。

Frid​​a 将允许在运行时窃取您的 OAuth 令牌并将它们发送到攻击者控制服务器，然后他们可以从那里重复使用它来向您的后端发起自动攻击，这将相信它们是合法的，因为 who 在请求中是有效的。

窃取 API 密钥甚至 OAuth 令牌的另一种方法是使用其他开源工具执行中间人 (MitM) 攻击，例如 mitmproxy：

一个交互式的支持 TLS 的拦截 HTTP 代理，供渗透测试人员和软件开发人员使用。

所以当攻击者使用 mitmproxy 拦截发往后端的请求时，他会看到如下内容：

图片来源于文章：Steal that API key with a Man in the Middle Attack

您是否注意到该 url 在https 中并包含一个 API 密钥？

那么到目前为止，您认为https 足以保护客户端和服务器之间的通信吗？

你想要什么

我想要什么：

我有两个前端应用程序。

Android 原生移动应用。 Nuxt SPA 前端应用

我的 API 应该只能在这些前端工作。其他邮递员或浏览器请求不应通过，并且可能应显示不受支持的平台 json msg。

网络应用

由于网络构建方式的性质，后端无法高度自信地识别是什么对任何类型的网络应用发出请求，无论是SPA 或传统的。

您能做的最好的事情是尽最大努力申请User Behavior Analytics(UBA)，告诉appart 谁和什么正在访问您的后端：

Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。 [1] UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。

使用 UBA 解决方案的一个很好的例子是使用 Google Recaptcha V3:

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。它使用先进的风险分析技术来区分人类和机器人。

这很容易出现误报，因此在决定是否接受基于the score returned by reCPATCHA V3 的每个请求的请求时需要小心：

reCAPTCHA v3 为每个请求返回一个分数，没有用户摩擦。该分数基于与您的站点的交互，使您能够为您的站点采取适当的操作。

对于移动应用程序

到目前为止，您已经知道用于识别您的用户的 OAuth 令牌并不像最初那样“安全”，因为它只识别请求中的 谁，而不是 是做什么的，正如您还可以从大量可用于对移动应用程序进行逆向工程的工具中看到的那样，OAuth 令牌始终处于被未经授权的客户窃取和滥用的危险中。

可以让您的后端确定请求确实来自与上传到 Google Play 商店的完全相同的移动应用的解决方案是移动应用证明解决方案，这是一个引入新方法的概念以统一的方式处理您的移动应用程序和后端的安全性。

通常的解决方案主要关注移动应用程序本身，但首先您要保护的数据位于后端服务器中，您希望在这里有一种机制来了解什么 提出的请求确实是您所期望的，是您真正的移动应用程序。

在我写的另一篇文章的this section 中描述了移动应用证明概念，我将在其中引用以下文字：

移动应用证明服务的作用是对发送请求的内容进行身份验证，因此只响应来自真正的移动应用实例的请求并拒绝来自未经授权的来源的所有其他请求。

为了了解向 API 服务器发送请求的内容，移动应用证明服务将在运行时以高可信度识别您的移动应用存在、未被篡改/重新打包、未运行在有根设备中，尚未被仪器框架（Frida、xPosed、Cydia 等）挂钩，也不是中间人攻击 (MitM) 的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明移动应用程序和运行它的设备的完整性。

成功证明移动应用程序的完整性后，将颁发一个短期 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。在证明失败的情况下，JWT 令牌使用不正确的密钥进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密，因此即使应用程序已被篡改、在根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这是 MitM 攻击的目标。

移动应用必须在每个 API 请求的标头中发送 JWT 令牌。这允许 API 服务器仅在可以验证 JWT 令牌已使用共享密钥签名并且尚未过期时才提供请求。所有其他请求将被拒绝。换句话说，有效的 JWT 令牌会告诉 API 服务器发出请求的是上传到 Google 或 Apple 商店的真正移动应用程序，而无效或丢失的 JWT 令牌意味着发出请求的东西未被授权这样做，因为它可能是机器人、重新打包的应用程序或进行中间人攻击的攻击者。

采用这种方法将使您的后端服务器非常有把握地知道 什么 发出请求，即您上传到 Google Play 的移动应用完全相同，前提是 JWT 令牌具有一个有效的签名和过期时间，并将所有其他请求作为不可信的请求丢弃。

总结

对于网络应用，您的保护更加有限，我认为后端的用户行为分析可能是您的最佳选择。

对于移动应用程序，存在大量解决方案，但它们专注于移动应用程序本身，使得后端容易受到模仿移动应用程序的请求的信任，但使用移动应用程序证明解决方案，后端能够区分来自正版手机和假手机的请求。

加倍努力

现在我想向您推荐 OWASP 基金会的优秀作品：

The Web Security Testing Guide:

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

The Mobile Security Testing Guide：

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

【讨论】：

那么，有没有办法保护这些后端api？

我已经在我的回复中提到了如何为网络应用程序和移动应用程序保护它。请参阅您想要什么部分。如果有什么让您感到困惑或不够清楚，请告诉我。