How To Add Security To Your Mobile App

In a previous article, we discussed “When do we add security into our app and onto our APIs?” The conclusion was to do it as soon as possible! That said, there are still choices to be made so in this article we explore how you should decide on appropriate protections for your mobile app and APIs.

When discussing when to build security into a mobile centric platform, it became clear that there are very good reasons to include it as early as possible. This allows you to focus on feature development and minimizes the risk that unplanned security events require diversion of your valuable technical resources to deal with them,  derailing your plans for market domination.  

When considering mobile apps and APIs, many security options exist and so it is important to logically work through the most appropriate ones for your use cases.  

What Threats Are Most Dangerous To Your Business?

The first step is to consider what threats you are most concerned about. Threats should not be prioritized based on the probability of a particular attack happening but rather on the impact that attack would have on your business if it did happen. 

For example, if you left a coat in the back of your car, it’s possible that someone might see the coat, break into your car and steal it. That would be annoying and inconvenient, but it would not stop you from carrying out your plans for that day. Conversely, if the car was stolen, that could prevent you from completing essential tasks such as attending a business meeting or visiting someone important. Therefore, although having a coat stolen might be more likely than losing a car, protection against car theft should be a higher priority. Once that is achieved, consideration should then be given to how to prevent items being stolen from the car - or even better - making sure they are not left in the car in the first place!

In order to see how this applies to mobile app and API security, let’s consider the 3 main components in the mobile platform and what options we have to protect them.

The Mobile App

Mobile apps are attacked for these primary reasons:

• To reverse engineer the code: Bad actors will look to examine the code in your app in order to understand the business logic within it, as well as search for any embedded secrets such as API keys, URLs, etc.
• To modify the code: The objective might be to repackage your mobile app so that it looks the same from the outside, but does something different under the hood - for example to direct funds to a bank account under the control of fraudsters. If a genuine user can be persuaded to install the modified app, this attack will be effective.
• To extract live sensitive data: Hackers may wish to ‘hook’ functions in a running instance of your mobile in order to access data that passes through the app, either to capture it for later use or to modify it on the fly to direct transactions their way.

It’s important to note that most of the reasons that bad actors attack mobile apps relate to extraction of data or intelligence that enables subsequent attacks against the whole platform. The primary vector used in those later cases is a script which impersonates genuine mobile app traffic. We’ll return to this topic later.

A number of security approaches are available to protect your mobile app code:

• Obfuscation: This means making your code hard to understand in order to make reverse engineering more difficult. Both free and commercial tools are available for this.
• Anti-tamper: This means utilizing tools to put mechanisms into your code to prevent attempts to modify your code. This is also referred to as runtime application self-protection (RASP).
• White-box cryptography: This means using tools to cryptographically combine code and secrets together to make them very hard to extract or even understand. The output software can therefore be run in a relatively insecure environment. 
• Code scanning: Tools are available to analyze your code and determine if vulnerabilities exist within it. This can be very useful to identify paths that hackers can use to attack your app but it should be remembered that many attack vectors exist which do not rely on vulnerabilities, in other words perfect software can still be hacked.

More information is available on the broad topics of in-app protection and mobile app shielding. 

The Mobile API

APIs that service mobile apps are attacked mainly to intercept and/or modify the data which is transmitted on them. Intercepted traffic is examined to understand the API protocol being used, and perhaps the relationship between actions in the mobile app and the resulting API transactions. The intention of such activity is reconnaissance for building scripts which will later be used to attack the platform.

Source: www.approov.io

The main mechanism used to attack APIs in this context is Man in the Middle (MitM) and although encrypting the traffic is straightforward to implement using TLS, it can relatively easily be decrypted. Certificate pinning is helpful too, but has some risks and challenges relating to both its implementation and management. 

For a full discussion about MitM and how best to mitigate it, check out our MitM whitepaper or a recording of our webinar on the topic.

The Backend Services

Generally speaking, most of the data and services of interest to bad actors are actually with the backend infrastructure. This is where the data lakes of sensitive data exist and where all of the major business logic resides. As a result, this is usually the target of hackers and the attacks are most commonly executed using scripts or bots.

Source: www.approov.io

There are 2 mechanisms being used in these cases:

• Exploitation of vulnerabilities: Bugs in the backend software code or in the APIs can be exploited in order to gain access to databases or to impact backend resources.
• Impersonation of mobile app traffic: Using information extracted from analysis of the mobile app and/or the APIs that service it, traffic patterns can be generated which contain valid credentials and which are indistinguishable from genuine mobile app traffic, in order to interact at scale with backend services undetected.

To consider how best to protect yourself from these attacks, it is important to recognise that the execution path is via a script, or a bot generating automated traffic. Once you realise that, the approach to protection may be simpler than you think; namely that if you can just identify the scripted traffic at the API endpoint, you can block it and only allow traffic from genuine mobile app instances to pass through to backend processing.

Two approaches you may wish to consider to protect mobile platforms are:

• Code scanning: This can be done on APIs or on backend server code and the purpose is to identify unintentional bugs or vulnerabilities in your code which attackers could exploit to gain access to your backend systems and data. Static and dynamic scans may reveal improvements that can be made to keep hackers at bay, but may also create false positives.
• Mobile app attestation: Remembering that being vulnerability free does not mean you are secure, it should be clear that another way to beat the scripts is to be able to verify whether or not each API request is coming from a genuine and unmodified mobile app instance, and that the app is running on an compromised mobile device. This allows you to differentiate between genuine and impersonated mobile API requests, with confidence. You can read more about mobile app attestation here.

These two security approaches are often called Shift Left, referring to the addition of secure code practices into the development phase, and Shield right, referring to the addition of security designed to protect software deployed in production. Check out our two part blog series on this topic; the first article is here.

Decisions, Decisions…

By now you will be thinking that there are a lot of different options when it comes to securing your mobile platform and you may be a bit confused about where to start. Obviously it isn’t possible to implement all of the options immediately and in fact some of them are probably not necessary. But which ones?

As mentioned above, the approach to follow is to consider the data and services that make up your mobile-centric platform and your use cases that leverage it. Then imagine different scenarios and consider the dangers they imply to your business. For example, what would happen if a user’s live data was extracted from a running app, or an API key was intercepted on an API, or a script impersonated your mobile app to send API requests to your backend? Take each of these and consider how well you could defend yourself against these attacks, and how much exposure you would have if they succeeded. This will help you to build a prioritized list of the protections you need.

Once you have this list then it should start to become clear what security mechanisms you should put in place first. For example, if you conclude that the most serious threat against your business is if your API key got into the hands of hackers and they used it in a script to extract sensitive data from your backend servers, then your highest priority activity is to shield your backend systems from scripts. Before reading this article, you might have thought that your first task should be to add obfuscation and anti-tamper protections in your app to make it more difficult to extract your API key; you should do that too of course, but not until you have first shielded your backend. 

In summary, first prevent the attack and second secure against intelligence gathering for the attack. If you would like to discuss your specific use cases and get some guidance on how to approach securing your mobile business, please contact one of our experts here.