Shielding APIs that Service Mobile Apps: Part 3 – How?

In the third part of this article series, we will look at the component parts of a shielding approach for APIs which service mobile apps and provide some guidance about what to consider when deploying a protective shield around your mobile business. 

In part 1 we covered the threats against your mobile app and API and in part 2 we looked at what shielding is in this context. Before looking at some solutions, let’s summarize again the main approaches to attacking your mobile channel.

Two API Attack Styles

As discussed in part 1, the mobile channel may be attacked through exploitation of vulnerabilities in the API or by abusing the API itself, as summarized below.

Image source: www.owasp.org (left) and www.approov.io (right)

When it comes to attacking the API through looking for vulnerabilities within it, we earlier looked at a BOLA vulnerability as a classic example of this but of course there are many others. Another type that we see quite often is excessive data exposure where an API, in response to a request from the mobile app, provides much more data than is actually required by the app. The interception and subsequent exposure of that data could be damaging as it could constitute a data breach against a user or a group of users. By way of illustration, an API response may provide additional personal information or location information for a user that may not be shown inside the app and this must be considered as a vulnerability in the API.

Exploitation of API vulnerabilities is one attack vector that you have to consider but let’s not forget about API abuse which does not involve vulnerabilities but is an attack executed by automating access to the API by a script that impersonates genuine mobile app traffic in order to exfiltrate the data. It’s important to note that such an approach is not constrained by the user interface that you put inside your mobile app; it extracts as much data as is available from the API and the attacker can then use it however they want. An example API abuse attack might be data scraping where data is exfiltrated from the back end system and then published on a website or sold on the dark web, depending on the type of data.

Two API Protection Approaches

We mentioned in part 2 that there are two API protection approaches that are required in order to cover these types of issues:

Image source: www.approov.io

As a reminder, the need to ‘shift left’ is to remove the vulnerabilities in your API by adopting better development practices, e.g. more rigorous coding methods and testing efforts to ensure those API vulnerabilities never make it into production. On the other hand, the need to ‘shield right’ is required to deal with API abuse by scripts and bots. An additional justification for shielding is that it also prevents attackers from being able to use any API vulnerabilities that are present. There are two reasons why this is important. Firstly, you can’t realistically shift left immediately, so there will always be some time before all the vulnerabilities in your APIs can be fixed and you must shield your APIs against them being exploited during the time you need to address them. Secondly, you need to consider vulnerabilities you have not yet noticed, or new ones that get added as your APIs evolve. Consequently there are multiple reasons to indicate that having a shielding layer in your mobile channel is really good security practice.

Image source: www.approov.io

In terms of what needs to be shielded, it has to be everything between the user and the service, in other words the 5 attack surfaces that we discussed in part 2 of this blog series. Specifically, we want to expand the trust envelope from the service right out over the communication to the mobile app, onto the mobile app itself, ensuring the integrity of the mobile app and also looking at the integrity of the device itself. Refer to part 2 for more details on this topic.

In summary, you have to look at this as a whole and you need to be certain that you know that all incoming API requests are coming from a shielded source. The big technical challenge here is that you want to shield all these things but how do you do it and what can you trust?

Image source: www.approov.io

As you might expect, the answer is that you can’t trust anything between the user and the service because of course all of it is actually in the public domain. You’re just seeing an HTTP request coming in that’s connecting to your back end service. You can’t really believe anything that the HTTP request is telling you. 

So you really have to verify using a technical means that every API call is really coming from a genuine untampered instance of your mobile app and that app was actually running in a safe mobile environment – bearing in mind that you can’t trust any data regarding the environment until you have categorically established that the app itself is genuine and therefore is reporting truthfully. You also need to establish that there is no interception going on in terms of the TLS between the mobile app and the back end service. 

If you can guarantee these things then you have the advantage that you can block all scripts/bots and you can block all modified/manipulated apps. Don’t forget that API requests from any of the above threat sources will come in with perfectly valid user credentials or a perfectly valid OAuth 2 user authorization token. In order to sort the good requests from the bad ones within a mobile channel you must be able to build in this strong trust level – and to do that, as well as user authentication, you need to have mobile app authentication.

Image source: www.approov.io

For inspiration in establishing a viable solution for this problem, let’s look at the aspects of user authentication which are well understood. There are three classic factors. You have ‘something that the user knows’ like a password – although we know that by itself isn’t very strong. That’s why you need other factors. Another factor would be ‘something you have’, for example a device authenticator app or access to a particular phone number (possession of the SIM which enables you to receive an SMS code which could be used as a second factor). Finally there’s the ‘something you are’ factor which these days is often a biometric characteristic such as a fingerprint or a face. This last factor allows the user to demonstrate something inherent about themselves to prove that they are present at runtime.

Image source: www.approov.io

If we consider this same approach but from the point of view of mobile app authentication then the ‘something you know’ aspect is the API key which is usually embedded in the app and presented with the API request. It’s like a password for the app but we know that it is likely quite easy to extract so it’s not very strong. 

There is a ‘what you have’ possession element within a mobile app in order for it to be able to prove its identity and this is typically a binding that happens when you first install the app and when you first onboard you might push some keys down into the iOS keychain or Android keystore. This is essentially a binding to the device which is fine but of course it has the inherent weakness that it requires an onboarding step. The perennial security challenge with onboarding is that it takes place before even a basic trust level has been established and is therefore open being gamed.

Finally there’s the ‘something you are’ factor which, in the mobile app context, is remote app attestation. This turns out to be the strongest aspect for us to rely on for security. This is where the app proves to the server that it really is a genuine and untampered version of your mobile app and this is achieved by means of a cryptographic proof. You might consider this remote attestation as being like biometrics for mobile apps, although you can also argue that it’s better because the attestation can be repeated invisibly at regular intervals, where biometrics are usually only used at the start of a session. This approach really takes mobile app/API shielding to the next level, proving to your back end service that you really are calling from the correct app. 

Approov Mobile App/API Protection

Approov protects mobile businesses by attesting that the mobile app is genuine, that it is running in a safe mobile environment and that the API traffic is not being intercepted. These checks are run every 5 minutes and a signal is passed to the API endpoint at your back end so that you can verify that the incoming API request is good, as shown below.

Image source: www.approov.io

Approov requires you only to add an SDK to your mobile app and a standard JSON web token (JWT) check at your API endpoint and you are ready to go. The whole process is overseen by the Approov cloud service and the communication between it and your mobile is invisibly handled by the Approov SDK.

Our website contains more details on the Approov solution, including an overview of the architecture, an explanation of how easy the solution is to deploy, and some examples of the experiences of our customers. To dive into the more technical aspects of Approov there are website sections on runtime app protection, mobile app attestation and dynamic certificate pinning which you might find useful.

In this article, we’ve considered what characteristics a security shield for a mobile app/API channel might look like to immediately block and repel the threat landscape we outlined in the first two parts of the series. In the final part, we will bring the story together and describe some immediate steps which companies can take to implement an effective shield around their mobile business.

*** This is a Security Bloggers Network syndicated blog from Approov Blog authored by David Stewart. Read the original post at: http://blog.approov.io/shielding-apis-that-service-mobile-apps-part-3-how