Mobile Apps Protection

with Client-Side Solutions - Fighting a Losing Battle (Part 1).

Fighting a Losing Battle

Mobile Apps Protection with Client-Side Solutions – Fighting a Losing Battle (Part 1)

May 21, 2020 1:42 pm

In this short series, we’ll review the available client-side solutions and explain where they fall short compared to API protection solutions.
Protecting mobile apps from automated threats such as brute force attacks, scraping, etc. under single or multiple identities is usually done with a device fingerprinting SDK at the app on the client side.

Device fingerprinting enables us to verify that what is accessing the server is indeed a “legit” application from a “legit” device.  It requires a security code injection into the app, which imposes limitations and extra costs on the overall DevOps process, as well as a need to track the customer-installed versions and update all clients to the current one, just before turning on the filtration process at the server.

But that isn’t where the story ends.  Rather, this is the end of the beginning. There are a bunch of fundamental flaws in this protection sequence that are major causes for concern – here we go:

let’s examine the flow between the client and the server

1. The API of the SDK code is compiled with the app. The SDK implementation code itself resides in an obfuscated library. A call to the SDK API is added in certain stages of the application flow, such as during session initiation.

2. The SDK implementation then polls device configuration parameters (e.g., device_id, resolution, installed applications, language) and encodes them into a long client token several hundreds of bytes in length, that is signed and sent to the server.

3. The client token is then verified by the server (e., checks that the signature structure is valid and that the encoded device data “makes sense”).
The device data is used to build the fingerprint token, which is then sent to the client for further communication identification.

4. The fingerprint token is appended to subsequent requests sent by the client to the server.

5. The fingerprint token sent by the client is checked by the server for protected APIs, and requests that cannot be validated are denied.

6. Aside from the requests’ source verification, the fingerprint token may be used (by the server) to limit the traffic coming from devices, based on device identity.

Normally this is enough to block non-sophisticated hackers

Here’s how. In order to run the automated script/bot the first time, the non-sophisticated attacker reverse-engineers the normal applicative flow and corresponding API calls. APIs are then called directly using script-based tools, such as curl and python.
As the flow generating the fingerprinting token is skipped, it will easily and obviously be rejected on the first attempt to access protected APIs.

Is this enough to block professional hackers as well?

Stay tuned for part 2 of this blogpost series, in which we’ll provide a detailed answer to this question.