Now I'm developing a microservices system use Nginx as gateway and Keycloak as authorization/authentication. A mobile app use openidconnect with grant_type=client_credentials to get tokens.
Grant type 'client_credentials' need client_id, client_secret in request body.
If someone use Fiddler to attack as man in the middle, he can know client id/secret, than he can be man-in-the-middle by using them to get access token.
So how to prevent this case of attack?
I'm using https, but I know Fiddler can decrypt https.
Please help me. Many thanks.
A mobile app use openidconnect with grant_type=client_credentials to get tokens.
To start with, as already pointed out by others this is not the correct grant type to use in a mobile app, instead you may want to with the authorization_code flow.
Read more about in this article:
We will now go through a minimal example of how to obtain an ID token for a user from an OP, using the authorisation code flow. This is the most commonly used flow by traditional web applications.
Grant type 'client_credentials' need client_id, client_secret in request body. If someone use Fiddler to attack as man in the middle, he can know client id/secret, than he can be man-in-the-middle by using them to get access token.
Considering that you decide to implement the correct OpenID Connect authorization flow for your mobile app, thus not revealing anymore your client_secret, an attacker can still use Fidller to MitM attack your connection and extract the the resulting Authorization token to authenticate the user of the mobile app in the API server, just like I show in the article
Steal that Api Key with a Man in the Middle Attack:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
While this article shows an attack to steal the Api Key, the principle is the same to steal any other secret or data from the request.
An attacker can also resort to an instrumentation framework to hook at run-time into the code of your mobile app and steal any secret from it, and a good example of such tools is 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.
So how to prevent this case of attack?
Preventing attacks in the client is possible until some degree, but ultimately you don't have the visibility for when attackers are able to bypass the security measures you have shipped inside the APK of your mobile app, because when a skilled attacker knows how to properly use an instrumentation Framework he will kook into the code that does the security decisions and make it always return that everything is ok.
So instead you want to shift your focus in allowing that your API server can reliably know that is indeed talking with the same exact APK you have released, not with a tampered and compromised one, or that the requests are coming from a bot.
Since the release of DeviceCheck for iOS and SafetyNet for Android, I see more and more developers referencing them as a form of attesting their mobile apps, but some are failing to understand for what this solutions are really designed for.
Let's take the own words of Google about SafetyNet:
- Using the SafetyNet Attestation API results as the only signal to attack abuse
It may be tempting to think that the SafetyNet Attestation API provides all the necessary signals for protecting an app against abusers, and use it as the only signal for building an anti-abuse system.
The SafetyNet Attestation API can only give signals about the state of a device, not the intent of a user, which is what an anti-abuse system should be designed to detect. Therefore, you might want to consider including other signals, such as access logs and behavioral patterns, to more accurately detect abusive users, and consider not blocking users solely on a failed attestation. Furthermore, there are many other conditions that cause an attestation to fail, such as network connection problems, quota issues, and other transient problems.
In other words, not all users who fail attestation are necessarily abusers, and not all abusers will necessarily fail attestation. By blocking users solely on their attestation results, you might be missing abusive users that don't fail attestations. Furthermore, you might also be blocking legitimate, loyal customers who fail attestations for reasons other than abuse.
I expand more about what a developer must be aware on this answer to the question Android equivalent of ios devicecheck.
So the bottom line is that in the case of SafetyNet it attests the mobile device not your mobile app, but it's still a good security mechanism to have in place.
For attesting that a mobile app is indeed not compromise or abused you need to employ a Mobile App Attestation solution.
A mobile app attestation role is to attest that the APK you upload is not at risk of being compromised or not already compromised, thus allowing for your API server to have an high degree of confidence that is indeed communicating with the genuine instance of your mobile app.
I invite you to read this answer I gave to another question that explains the concept in more detail while at same time gives you some more context why it may be a better fit to solve your problem.
So if you put together Mobile App Attestation with Mobile Device Attestation, then you may have found the best solution to secure your mobile app from being abused due to compromised OAuth credentials.
In any response to a security question I always like to reference the awesome work from the OWASP foundation, thus here it goes:
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.