未经授权的API调用-安全并仅允许注册的前端应用程序 [英] Unauthorized API Calls - Secure and allow only registered Frontend app
问题描述
我在 Laravel 中具有后端api，并使用 Laravel Passport(OAuth2).我看到OAuth2非常酷，可以保护我的身份验证请求(使用laravel中的api中间件)，并且只允许授权用户访问.
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.
但是我可以访问后端api以进行未经授权的使用，例如
But i can access the backend api for unauthorised usage for example
路由:(/register)或(/login)，没有任何api密钥.大多数攻击者将在网络"选项卡中看到此api调用，并且可以发送DDOS攻击.由于Laravel Passport具有内置的限速功能，因此除非我手动允许，否则我仍然不希望人们访问我的后端api.
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.
我想要什么:
我有两个前端应用程序.
I have two frontend apps.
- Android Native Mobile应用.
- Nuxt SPA前端应用程序
我的API仅应从这些前端运行.没有其他邮递员或浏览器请求可以通过，并且可能应显示不受支持的平台json消息.
My API should work only from these frontends. No other postman or browser request should pass and probably should display unsupported platforms json msg.
推荐答案
它们真的可以保护您的后端吗?
我看到OAuth2非常酷，可以保护我的身份验证请求(使用laravel中的api中间件)，并且只允许授权用户访问.
I see OAuth2 is super cool and secures my auth request (with api middleware in laravel) and allow access only to authorized users.
它不仅允许授权用户访问任何显示有效OAuth令牌的请求.这是开发人员中常见的误解，因为OAuth令牌仅表示请求中的谁，而不是发出请求的什么，我在本文，您可以在其中阅读:
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:
什么是向API服务器发出请求的东西.它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛?
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?
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和标识，例如使用OpenID Connect或OAUTH2流.
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.
本文是在移动应用程序的上下文中使用的，但是对于mobile app和web app而言，该概念是相同的，因为它们了解谁和 正在向后端服务器发出请求.
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.
但是我可以访问后端api以进行未经授权的使用，例如
But i can access the backend api for unauthorised usage for example
我希望到现在为止您已经意识到，不仅您通往/register和/login的路线有被滥用的危险，因为目前您只知道谁请求，而不是是什么.
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.
路由:(/注册)或(/登录)，没有任何api键.
Routes: (/register) or (/login) without any api key.
即使在此路由上具有API密钥，也不会阻止它被用作凭据填充攻击.
Even if you have an API key on this routes, it would not prevent it from being abused for credential stuffing attacks.
为什么你会问?
在Web应用程序中，提取API密钥所需的全部操作是点击F12以打开开发人员工具"标签并进行搜索，或者查看页面源代码.
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.
您可以使用 MobSF 之类的工具来对任何移动应用进行反向工程二进制文件，然后从中提取API密钥或任何机密.我写了文章 Android隐藏秘密回购.
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.
MobSF :
移动安全框架(MobSF)是一种自动化的多合一移动应用程序(Android/iOS/Windows)可以进行静态和动态分析的笔测试，恶意软件分析和安全评估框架.
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.
如果您无法通过静态分析提取API密钥，则可以使用开放源代码工具进行动态分析，例如 Frida :
If you cannot extract the API key via static analysis, then you can resort to dynamic analysis with open source tools to, like Frida:
将您自己的脚本注入黑匣子进程.挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码.编辑，点击保存，立即查看结果.全部没有编译步骤或程序重新启动.
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将允许在运行时窃取您的OAuth令牌并将其发送给攻击者控制服务器，然后他们可以从那里重新使用它来向您的后端发起自动攻击，这会相信它们是合法的，因为 在请求中有效.
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.
窃取API密钥甚至OAuth令牌的另一种方法是使用其他开源工具(例如 mitmproxy :
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:
面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理.
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
因此，当攻击者使用mitmproxy拦截向后端发出的请求时，他将看到类似以下内容:
So when attacker uses mitmproxy to intercept the request being made to the backend, he will see something like this:
图片来自文章:隐藏该API密钥和一个处于中间攻击状态的人
您是否注意到URL在https中并且包含API密钥?
Did you noticed that the url is in https and contains an API Key?
所以直到现在，您虽然https足以确保客户端和服务器之间的通信安全?
So until now you though that https was enough to secure the communication between clients and server?
我想要什么:
What i want:
我有两个前端应用程序.
I have two frontend apps.
Android Native Mobile应用. Nuxt SPA前端应用程序
Android Native Mobile app. Nuxt SPA frontend app
我的API仅应从这些前端运行.没有其他邮递员或浏览器请求应通过，并且可能应显示不受支持的平台json消息.
My API should work only from these frontends. No other postman or browser request should pass and probably should display unsupported platforms json msg.
网络应用
由于网络构建方式的本质，后端无法高度自信地确定什么正在请求任何类型的Web应用程序，无论是SPA或传统SPA.
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.
您能做的最好的事情就是最好地应用用户行为分析(UBA)告知appart 谁和什么正在访问您的后端的依据:
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:
Gartner定义的用户行为分析(UBA)是一个有关检测内部威胁，针对性攻击和财务欺诈的网络安全流程. UBA解决方案着眼于人类行为的模式，然后应用算法和统计分析从这些模式中检测出有意义的异常，即表明潜在威胁的异常.[1] UBA不会跟踪设备或安全事件，而是跟踪系统的用户.
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.
使用UBA解决方案的一个很好的例子是使用 Google Recaptcha V3 :
A good example of using a UBA solution is to use Google Recaptcha V3:
reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害.它使用先进的风险分析技术来区分人和机器人.
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.
这容易产生误报，因此在决定是否接受基于 reCPATCHA V3针对每个请求返回的分数:
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会为每个请求返回一个分数，而不会引起用户的困扰.得分基于与您的网站的互动情况，使您能够对自己的网站采取适当的措施.
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.
对于移动应用
现在，您已经知道，用来标识用户的OAuth令牌不像您最初那样安全"，因为它只能标识请求中的谁，而不是 正在做的事情，正如您还可以通过大量用于反向工程移动应用程序的工具所看到的那样，OAuth令牌始终处于被未授权客户端窃取和滥用的危险中.
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.
该解决方案可以使您的后端确保请求确实来自上传到Google Play商店的同一移动应用，这是一种移动应用证明解决方案，该概念引入了一种新的解决方案以统一的方式处理您的移动应用程序和后端的安全性.
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.
为了知道是什么向API服务器发送了请求，移动应用程序证明服务将在运行时高度肯定地标识您的移动应用程序存在，未被篡改/重新打包，未运行在具有根权限的设备中，它还没有被工具框架(Frida，xPosed，Cydia等)迷住，并且不是中间人攻击(MitM)的对象.这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信，以证明移动应用程序及其所运行的设备的完整性.
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.
在成功证明移动应用程序完整性后，将发布并使用一个秘密的短期生存的JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务才能知道.在证明失败的情况下，将使用错误的机密对JWT令牌进行签名.由于移动应用程序不知道移动应用程序证明服务使用的机密，因此即使在应用程序已被篡改，在有根设备中运行或通过连接进行通信时，也无法在运行时对其进行反向工程这是MitM攻击的目标.
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.
移动应用必须在每个API请求的标头中发送JWT令牌.这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名并且尚未到期时才服务于请求.所有其他请求将被拒绝.换句话说，有效的JWT令牌告诉API服务器发出请求的是上传到Google或Apple商店的真正的移动应用程序，而无效或丢失的JWT令牌意味着发出请求的内容未经授权，因为它可能是机器人，重新打包的应用程序或发起MitM攻击的攻击者.
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.
采用这种方法将使您的后端服务器非常有把握地知道是什么，只要JWT令牌具有相同的移动应用程序，该请求与您上传到Google Play的确切移动应用程序相同有效的签名和到期时间，并将所有其他请求视为不可信的请求.
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.
对于Web应用程序，您的保护受到更大的限制，我认为后端的用户行为分析可能是您的最佳选择.
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.
现在，我想向您推荐OWASP基金会的出色工作:
Now I would like to recommend you the excellent work of the OWASP foundation:
OWASP Web安全测试指南包括用户可以在自己的组织中实施的最佳实践"渗透测试框架，以及描述了测试最常见的Web应用程序和Web服务安全问题的技术的低水平"渗透测试指南.
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.
移动安全测试指南(MSTG)是用于移动应用安全开发，测试和逆向工程的综合手册.
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
这篇关于未经授权的API调用-安全并仅允许注册的前端应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
