android - 未经授权的 API 调用 - 安全且仅允许注册的前端应用程序
问题描述
我在Laravel中有后端 api并使用Laravel Passport(OAuth2)。我看到 OAuth2 非常酷，可以保护我的身份验证请求（在 laravel 中使用 api 中间件），并且只允许授权用户访问。
但我可以访问后端 api 以进行未经授权的使用，例如
路由： ( /register) 或 ( /login) 没有任何 api 密钥。大多数攻击者会在网络选项卡中看到此 api 调用，并可以发送 DDOS 攻击。由于 Laravel Passport 内置了速率限制，我仍然不希望人们访问我的后端 api，除非我手动允许它。
我想要的是：
我有两个前端应用程序。
- Android 原生移动应用。
- Nuxt SPA 前端应用
我的 API 应该只能在这些前端工作。没有其他邮递员或浏览器请求应该通过，并且可能应该显示不受支持的平台 json msg。
解决方案
OAUTH 令牌真的足以保护您的后端吗？
我看到 OAuth2 非常酷，可以保护我的身份验证请求（在 laravel 中使用 api 中间件），并且只允许授权用户访问。
它允许访问提供有效 OAuth 令牌的任何请求，而不仅仅是授权用户。这是开发人员中常见的误解，因为 OAuth 令牌仅代表请求中的人员，而不是发出请求的内容，我在本文中对此进行了更详细的讨论，您可以在其中阅读：
向 API 服务器发出请求的内容是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
这篇文章是在一个移动应用程序的上下文中，但是这个概念是相同的，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，您可以按照此操作的实际示例进行操作，还向您展示了使用Android Hide在移动应用程序中隐藏 API 密钥的几种技术来自 Github 的Secrets仓库。
暴徒：
移动安全框架 (MobSF) 是一种自动化的一体化移动应用程序 (Android/iOS/Windows) 渗透测试、恶意软件分析和安全评估框架，能够执行静态和动态分析。
如果您无法通过静态分析提取 API 密钥，那么您可以使用开源工具进行动态分析，例如Frida：
将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。
Frida 将允许在运行时窃取您的 OAuth 令牌并将它们发送到攻击者控制服务器，然后他们可以从那里重用它来向您的后端发起自动攻击，这将相信它们是合法的，因为请求中的谁是有效的。
窃取 API 密钥甚至 OAuth 令牌的另一种方法是使用其他开源工具（例如 mitmproxy）执行中间人（MitM）攻击：
一个交互式的支持 TLS 的拦截 HTTP 代理，适用于渗透测试人员和软件开发人员。
因此，当攻击者使用 mitmproxy 拦截向后端发出的请求时，他会看到如下内容：
图片来自文章：Steal that API key with a Man in the Middle Attack
您是否注意到该 url 在https其中并包含一个 API 密钥？
那么到目前为止，您认为这https足以保护客户端和服务器之间的通信吗？
你想要什么
我想要的是：
我有两个前端应用程序。
Android 原生移动应用。Nuxt SPA 前端应用
我的 API 应该只能在这些前端工作。没有其他邮递员或浏览器请求应该通过，并且可能应该显示不受支持的平台 json msg。
网络应用程序
由于 Web 构建方式的性质，后端无法高度自信地识别出对任何类型的 Web 应用程序的请求，无论是 SPA 还是传统应用程序。
您可以做的最好的事情是尽最大努力应用用户行为分析 (UBA)来告诉 appart谁和什么正在访问您的后端：
Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、有针对性的攻击和金融欺诈的网络安全流程。UBA 解决方案着眼于人类行为的模式，然后应用算法和统计分析从这些模式中检测有意义的异常——表明潜在威胁的异常。 [1] UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。
使用 UBA 解决方案的一个很好的例子是使用 Google Recaptcha V3：
reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。它使用先进的风险分析技术来区分人类和机器人。
这很容易出现误报，因此在根据reCPATCHA V3为每个请求返回的分数决定是否接受请求时需要小心：
reCAPTCHA v3 为每个请求返回一个分数，没有用户摩擦。该分数基于与您的站点的交互，使您能够为您的站点采取适当的操作。
对于移动应用
到目前为止，您已经意识到用于识别您的用户的 OAuth 令牌并不像最初那样“安全”，因为它只识别请求中的谁，而不是在做什么，而且正如您所看到的那样在可用于对移动应用程序进行逆向工程的工具中，OAuth 令牌始终面临被未经授权的客户窃取和滥用的危险。
可以让您的后端确定请求确实来自与上传到 Google Play 商店的完全相同的移动应用程序的解决方案是移动应用程序证明解决方案，这是一个引入处理安全性的新方法的概念以统一的方式为您的移动应用程序和后端。
通常的解决方案主要关注移动应用程序本身，但首先您要保护的数据在您的后端服务器中，在这里您需要一种机制来知道发出请求的内容确实是问题所在您期望的，您真正的移动应用程序。
我写的另一篇文章的这一部分描述了移动应用证明概念，我将在其中引用以下文本：
移动应用程序证明服务的作用是验证发送请求的内容，因此仅响应来自真正移动应用程序实例的请求并拒绝来自未经授权来源的所有其他请求。
为了了解向 API 服务器发送请求的内容，移动应用证明服务将在运行时以高可信度识别您的移动应用存在、未被篡改/重新打包、未在根目录中运行设备，尚未被仪器框架（Frida、xPosed、Cydia 等）挂钩，也不是中间人攻击 (MitM) 的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明运行它的移动应用程序和设备的完整性。
在成功证明移动应用程序完整性后，将发布一个短期 JWT 令牌并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。在证明失败的情况下，JWT 令牌使用不正确的密钥进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密，因此即使应用程序已被篡改、在根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这是 MitM 攻击的目标。
移动应用程序必须在每个 API 请求的标头中发送 JWT 令牌。这允许 API 服务器仅在可以验证 JWT 令牌已使用共享密钥签名并且尚未过期时才提供请求。所有其他请求将被拒绝。换句话说，有效的 JWT 令牌会告诉 API 服务器发出请求的是上传到 Google 或 Apple 商店的真正移动应用程序，而无效或丢失的 JWT 令牌意味着发出请求的东西没有被授权这样做，因为它可能是机器人、重新打包的应用程序或进行中间人攻击的攻击者。
采用这种方法将使您的后端服务器非常有把握地知道发出请求的内容，即您上传到 Google Play 的完全相同的移动应用程序，前提是 JWT 令牌具有有效的签名和过期时间，并丢弃所有其他请求为不可信请求。
概括
对于 Web 应用程序，您的保护更加有限，我认为后端的用户行为分析可能是您的最佳选择。
对于移动应用程序，存在大量过多的解决方案，但它们专注于移动应用程序本身，使得后端容易受到模仿移动应用程序的请求的信任，但使用移动应用程序证明解决方案，后端能够区分请求和真实请求手机和假的。
加倍努力
现在向大家推荐 OWASP 基金会的优秀作品：
OWASP Web 安全测试指南包括一个“最佳实践”渗透测试框架，用户可以在他们自己的组织中实施它和一个“低级”渗透测试指南，描述了测试最常见的 Web 应用程序和 Web 服务安全问题的技术。
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。