Menu
How to protect my backend from being accessed by other unauthorised front-end apps? I googled and couldn't find a solution that gives complete solution. How companies like Instagram,Facebook block unauthorised requests ? I read SSL keys can be found by reverse-engineering the front-end. I am a noob and building a social network for a project.Please guide me.
523
How to protect my backend from being accessed by other unauthorised front-end apps?
By front end apps I will assume you mean both mobile and web apps, and once my expertise is more in mobile apps and API security I will focus on mobile, but I will give you some pointer to web apps to.
I googled and couldn't find a solution that gives complete solution.
Let me tell you a cruel truth, that's because it doesn't exist. What exists it's defense in depth where you apply as many layers as you can afford in order to protect your backend.
It's a common belief among developers that using https in conjunction with user authentication, be it with OAUTH providers, your own JWT implementations, or with the traditional sessions and cookies, are enough to protect a backend from unauthorized access, but this is far from being 100% effective, because to start with, user authentication only identifies WHO is accessing the backend,the user, not WHAT is accessing it.
You can think of the WHAT as it is your genuine app doing the request in behalf of WHO you think, even if presenting a valid token? Or it is the request coming from an automated script with a stolen token, or from a tool like Postman? You can read more about in this section of article I wrote about API keys.
I read SSL keys can be found by reverse-engineering the front-end.
If the front-end is a web app, then it's trivial to find any secret on it, just hit F12 to access the developers tools in the browser or right click to inspect the page source.
If the front-end is a mobile app, then some developers may think they are in the safe side just because the mobile app its released as a binary file, but that's a false sense of security, because a lot of tooling exists to perform static binary analysis on them, and you can read this other article I wrote to understand how to use the Mobile Security Framework to extract an API key from a mobile app binary.
If static binary analysis is not enough, than in devices the attacker have control off he can perform a MitM(Man in the Middle) attack, where he intercepts all communications between the app and the backend. I have an article about a MitM in the context of a mobile app, that you can read more about here, where you will learn how to steal an API key with the open source tool mitmproxy, or they can resort to a more advanced approach by hooking an instrumentation framework during the runtime, for example 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.
How companies like Instagram,Facebook block unauthorised requests ?
They will use some kind of short lived token or other mechanism to identify the user, but as I already mentioned this is only to identify WHO is in the request. For them to know WHAT is doing the request they may resort to machine learning and artificial intelligence to perform User Behavior Analytics(UBA) on the incoming requests in order to detect unusual human behaviors and block them, and you can read more in Wikipedia:
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.
As you can read UBA tracks humans, by other words the WHO in the request. They do this in an attempt to distinguish between WHO and WHAT is doing the request, and as you may be thinking, this is prone to false positives, thereby the rules in policies applied in this types of systems need to take it in account.
I am a noob and building a social network for a project.Please guide me.
While UBA solutions are prone to false positives, they may be the best for a backend serving a web app. To roll your own UBA solution it will be very expensive, because it require a lot of resources, expertise and time, and to buy a commercial one it may be out of budget, therefore your best bet may be the Google reCAPTCHA V3:
reCAPTCHA v3 helps you detect abusive traffic on your website without user interaction. Instead of showing a CAPTCHA challenge, reCAPTCHA v3 returns a score so you can choose the most appropriate action for your website.
To defend an API backend serving a mobile app I would recommend you to read the series of blog posts about Mobile API Security where you will see how several defenses can be implemented and bypassed, like OAUTH JWT tokens, and you can read this other series of blog posts that will show you a fictional app and a fictional attacker defeating API Keys, OAUTH JWT tokens, and requests signed with HMAC.
For a backend of a mobile app the best approach to defend it from unauthorized requests is to use a Mobile App Attestation solution, that in short will allow for the backend to identify WHAT is doing the request without the need for any kind of secret to be shipped in the app, like the traditional API keys, and I go in more detail about the role of a Mobile App Attestation in this section of an article about certificate pinning, where you can read:
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.
A great benefit of using a Mobile App Attestation service is its proactive and positive authentication model, which does not create false positives, and thus does not block legitimate users while it keeps the bad guys at bay.
In security questions I always like to end by recommending the excellent work from OWASP:
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.
131
I'll try to get you started in the right direction.
How to protect my backend from being accessed by other unauthorised front-end apps?
You can protect your server by issuing access tokens. The only way a user can get a valid token is by authenticating with a valid username and password.
Typically, tokens are set to expire after a period of time. If you are looking for a turn key solution, JSON web tokens are a good place to start. More info here: https://jwt.io/
I googled and couldn't find a solution that gives complete solution. How companies like Instagram,Facebook block unauthorised requests ?
Facebook uses access tokens. https://developers.facebook.com/docs/facebook-login/access-tokens/
I read SSL keys can be found by reverse-engineering the front-end.
Access tokens can't be reverse engineered because they are not 'hard-coded' into the front-end. The access tokens are retrieved from the back-end via authentication. Additionally, tokens typically expire after a period of time. If the token has expired, then the user must re authenticate to receive a new (valid) token.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
