未经授权的 API 调用 - 保护并只允许注册的前端应用 [英] Unauthorized API Calls - Secure and allow only registered Frontend app
问题描述
我在 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 令牌仅代表谁在请求中，而不是什么发出请求，我在
您是否注意到 url 在 https 中并包含 API 密钥?
那么到目前为止，您是否认为 https 足以保护客户端和服务器之间的通信?
你想要什么
<块引用>我想要的:
我有两个前端应用.
Android 原生移动应用.Nuxt SPA 前端应用
我的 API 应该只能在这些前端工作.不应通过其他邮递员或浏览器请求，并且可能应显示不受支持的平台 json msg.
网络应用
由于网络构建方式的性质，后端无法高度自信地识别对任何类型的网络应用程序的请求，无论是什么SPA 或传统的.
您能做的最好的事情就是最好地应用用户行为分析(UBA)告诉应用程序谁和什么正在访问您的后端:
<块引用>Gartner 定义的用户行为分析 (UBA) 是一种关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程.UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测有意义的异常——表明潜在威胁的异常.[1]UBA 不跟踪设备或安全事件，而是跟踪系统的用户.
使用 UBA 解决方案的一个很好的例子是使用Google Recaptcha V3:
<块引用>reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用.它使用先进的风险分析技术来区分人类和机器人.
这很容易出现误报，因此在根据 reCPATCHA V3 为每个请求返回的分数:
<块引用>reCAPTCHA v3 在没有用户摩擦的情况下为每个请求返回一个分数.该分数基于与您网站的互动，使您能够为您的网站采取适当的操作.
对于移动应用
到目前为止，您已经知道用于识别用户的 OAuth 令牌并不像您最初那样安全"，因为它仅识别请求中的who，而不是 正在做什么，正如您从大量可用于对移动应用程序进行逆向工程的工具中看到的那样，OAuth 令牌总是有被未经授权的客户端窃取和滥用的危险.
可以让您的后端确保请求确实来自上传到 Google Play 商店的完全相同的移动应用程序的解决方案是移动应用程序证明解决方案，这是一个引入了新方法的概念以统一的方式处理您的移动应用程序和后端的安全性.
通常的解决方案主要关注移动应用程序本身，但首先，您要保护的数据位于后端服务器中，您希望在这里有一种机制来了解什么strong> 提出的请求确实是您所期望的，是您真正的移动应用.
移动应用证明概念在本节我写的另一篇文章，我将引用以下文字:
<块引用>移动应用证明服务的作用是验证发送请求的内容，从而仅响应来自真正移动应用实例的请求并拒绝来自未经授权来源的所有其他请求.
为了了解向 API 服务器发送请求的内容，移动应用证明服务会在运行时高度确定您的移动应用存在、未被篡改/重新打包、未运行在有根设备中，尚未被检测框架(Frida、xPosed、Cydia 等)连接，并且不是中间人攻击 (MitM) 的对象.这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明其运行的移动应用和设备的完整性.
在成功证明移动应用程序完整性后，系统会发出一个短期存在的 JWT 令牌，并使用只有云中的 API 服务器和移动应用程序证明服务知道的秘密进行签名.在证明失败的情况下，JWT 令牌使用不正确的秘密进行签名.由于移动应用证明服务使用的秘密不被移动应用知道，因此即使应用被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这就是中间人攻击的目标.
移动应用必须在每个 API 请求的标头中发送 JWT 令牌.这允许 API 服务器仅在可以验证 JWT 令牌是否已使用共享密钥签名且未过期时才提供请求.所有其他请求将被拒绝.换句话说，一个有效的 JWT 令牌告诉 API 服务器发出请求的是上传到 Google 或 Apple 商店的正版移动应用程序，而无效或丢失的 JWT 令牌意味着发出请求的内容没有被授权这样做，因为它可能是机器人、重新打包的应用或发起中间人攻击的攻击者.
采用这种方法将使您的后端服务器以非常高的信心什么发出请求，与您上传到 Google Play 的移动应用完全相同，前提是 JWT 令牌具有一个有效的签名和过期时间，并将所有其他请求作为不可信的请求丢弃.
总结
对于网络应用，您的保护更为有限，在我看来，后端的用户行为分析可能是您的最佳选择.
对于移动应用程序，存在大量的解决方案，但它们专注于移动应用程序本身，使后端容易受到模仿移动应用程序的请求的信任，但通过移动应用程序证明解决方案，后端能够区分来自真手机和假手机的请求.
走得更远
现在向大家推荐OWASP基金会的优秀作品:
<块引用>OWASP Web 安全测试指南包括一个最佳实践"渗透测试框架，用户可以在他们自己的组织中实施该框架，以及一个低级"渗透测试指南，描述测试最常见的 Web 应用程序和 Web 服务安全问题的技术.
<块引用>移动安全测试指南 (MSTG) 是一本关于移动应用安全开发、测试和逆向工程的综合手册.
I have backend api in Laravel and using Laravel Passport(OAuth2). I see OAuth2 is super cool and secures my auth request (with api middleware in laravel) and allow access only to authorized users.
But i can access the backend api for unauthorised usage for example
Routes: (/register) or (/login) without any api key. Most attackers will see this api call in network tab and can send DDOS attack. Since Laravel Passport has rate-limiting inbuilt, still i don't want people to access my backend api, unless i allow it manually.
What i want:
I have two frontend apps.
- Android Native Mobile app.
- Nuxt SPA frontend app
My API should work only from these frontends. No other postman or browser request should pass and probably should display unsupported platforms json msg.
OAUTH TOKENS ARE THEY REALLY ENOUGH TO PROTECT YOUR BACKEND?
I see OAuth2 is super cool and secures my auth request (with api middleware in laravel) and allow access only to authorized users.
It allows access to any request that presents a valid OAuth token, not only for authorized users. This is an usual misconception among developers, because the OAuth token only represents who is in the request, not what is making the request, and I discussed this in more detail in this article, where you can read:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
The article is in the context of a mobile app, but the concept is the same for both the mobile app and web app in terms of knowing the difference between who and what is making the request to the backend server.
UNAUTHORIZED USAGE OF THE BACKEND
But i can access the backend api for unauthorised usage for example
I hope that by now you have realized that is not only your routes to /register and /login that are at danger of being abused, because at the moment you only know who is making the request, not what is making it.
Routes: (/register) or (/login) without any api key.
Even if you have an API key on this routes, it would not prevent it from being abused for credential stuffing attacks.
Why you may ask?
Well in a web app all it's needed to extract an API key is to hit F12 to open the developer tools tab and search for it, or view the page source.
You may now think, oh but in my mobile app it would not be possible, because it's a binary, and I even use obfuscation. Despite being a little more difficult is not hard, because a lot of open source tools exist to help with the task.
Reverse Engineering
You can use a tool like MobSF to reverse engineer any mobile app binary, and extract the API key or any secret from it. I wrote the article How to Extract an API Key from a Mobile App by Static Binary Analysis that you can follow for a practical example of doing it so, and also shows you several techniques to hide the API key in a mobile app with the Android Hide Secrets repo from Github.
Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.
If you cannot extract the API key via static analysis, then you can resort to dynamic analysis with open source tools to, like Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Frida will allow at runtime to steal your OAuth tokens and sent them to the attackers control servers, from where they can then reuse it to launch automated attacks to your backend, that will trust they are legit, because the who in the request is valid.
Another approach to steal an API key or even OAuth tokens is to perform a Man in the Middle(MitM) Attack wit another open source tools, like mitmproxy:
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
So when attacker uses mitmproxy to intercept the request being made to the backend, he will see something like this:
Image sourced from article: Steal that API key with a Man in the Middle Attack
Did you noticed that the url is in https and contains an API Key?
So until now you though that https was enough to secure the communication between clients and server?
WHAT YOU WANT
What i want:
I have two frontend apps.
Android Native Mobile app. Nuxt SPA frontend app
My API should work only from these frontends. No other postman or browser request should pass and probably should display unsupported platforms json msg.
The web apps
Due to the nature of how the web was built it's not possible for the backend to identify, with an high degree of confidence, what is making the request for any type of web app, be it a SPA or the traditional ones.
The best you can do is to apply User Behavior Analytics(UBA) in a best effort basis to tell appart who and what is accessing your backend:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats.[1] Instead of tracking devices or security events, UBA tracks a system's users.
A good example of using a UBA solution is to use Google Recaptcha V3:
reCAPTCHA is a free service that protects your site from spam and abuse. It uses advanced risk analysis techniques to tell humans and bots apart.
This is prone to false positives, therefore you need to be careful when deciding to accept or not the request based on the score returned by reCPATCHA V3 for each request:
reCAPTCHA v3 returns a score for each request without user friction. The score is based on interactions with your site and enables you to take an appropriate action for your site.
For mobile apps
By now you are already aware that the OAuth token to identify your user is not that "safe" as you had though initially, because it only identifies the who in the request, not what is doing it, and as you also saw by the plethora of tools available to reverse engineer mobile apps, the OAuth token is always at danger of being stolen and abused by unauthorized clients.
The solution that can let your backend to be sure that the request is indeed from the same exact mobile app that was uploaded to the Google Play store is a Mobile App Attestation solution, and this is a concept that introduces a new approach of dealing with security for your mobile app and backend in an unified manner.
The usual solutions focus to much on the mobile app itself, but in first place the data you want to protect is in your backend server, and it's here that you want to have a mechanism to know that what is making the request is really the thing you expect, your genuine mobile app.
The Mobile App Attestation concept is described in this section of another article I wrote, from where I will quote the following text:
The role of a Mobile App Attestation service is to authenticate what is sending the requests, thus only responding to requests coming from genuine mobile app instances and rejecting all other requests from unauthorized sources.
In order to know what is sending the requests to the API server, a Mobile App Attestation service, at run-time, will identify with high confidence that your mobile app is present, has not been tampered/repackaged, is not running in a rooted device, has not been hooked into by an instrumentation framework (Frida, xPosed, Cydia, etc.) and is not the object of a Man in the Middle Attack (MitM). This is achieved by running an SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device it is running on.
On a successful attestation of the mobile app integrity, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud know. In the case that attestation fails the JWT token is signed with an incorrect secret. Since the secret used by the Mobile App Attestation service is not known by the mobile app, it is not possible to reverse engineer it at run-time even when the app has been tampered with, is running in a rooted device or communicating over a connection that is the target of a MitM attack.
The mobile app must send the JWT token in the header of every API request. This allows the API server to only serve requests when it can verify that the JWT token was signed with the shared secret and that it has not expired. All other requests will be refused. In other words a valid JWT token tells the API server that what is making the request is the genuine mobile app uploaded to the Google or Apple store, while an invalid or missing JWT token means that what is making the request is not authorized to do so, because it may be a bot, a repackaged app or an attacker making a MitM attack.
Taking this approach will let your backend server to know with a very high degree of confidence what is making the request, the same exact mobile app you uploaded to the Google Play, provided the JWT token has a valid signature and expire time, and discard all other requests as untrustworthy ones.
SUMMARY
For web apps your protection is more limited, and in my opinion User Behavior analytics in the backend may be the best option for you.
For mobile apps a huge plethora of solutions exist, but they focus on the mobile app itself, leaving the backend vulnerable to trust in requests that mimic the mobile app, but with a Mobile App Attestation solution the backend is able to tell apart requests from genuine mobile and from fake ones.
GOING THE EXTRA MILE
Now I would like to recommend you the excellent work of the OWASP foundation:
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
The Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
这篇关于未经授权的 API 调用 - 保护并只允许注册的前端应用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
