Mobile Apps, APIs, and Secrets

This article is featured in the new DZone Guide to Dynamic Web and Mobile Development. Get your free copy for more insightful articles, industry statistics, and more!

With consumers now preferring mobile apps on their portable devices rather than websites on their laptops/desktops, mobile app development is an essential component in any enterprise software product lifecycle. While websites don't necessarily need APIs to serve their content, APIs are needed in the majority of the use cases for mobile apps. This adds a new layer of complexity in terms of software development, deployment, maintenance, and, as will be explained in this article, security.

Before APIs existed, in order to get data from third-party websites, the approach was to scrape the website HTML — producing unstructured data through a process that was both complex and prone to error. Helpfully, for the scrapers, modern APIs have a set of endpoints that return structured data, making its unauthorized collection and reuse so much easier.

Let's now take a look at how to keep a mobile app secure and free of risky secrets while guaranteeing that the API backend server knows with certainty that it is communicating with a genuine instance of the mobile app, even when the app is running in compromised environments, such as on rooted and jailbroken devices.

Securing the Communication Channel

First up, the mobile app must only communicate over an HTTPS secure channel to protect the confidentiality, integrity, and authentication of the requests from man-in-the-middle-attacks.

While the inexperienced developer may imagine that this is sufficient to secure communications between a mobile and an API server to keep all sensitive information away from attackers, experience tells us that these protocols are vulnerable. Older SSL or TLS 1.0 implementation shave been deprecated due to recent attacks against them, such as the Poodle attack, that in the end allows an attacker to gain access to supposedly protected data.

Even with the use of more secure protocols, an attacker can perform man-in-the-middle attacks against the API server and a mobile app installed in a device he controls in order to be able to extract all secrets and understand how the app queries the API server and what responses he gets back.

For further security, Certificate Pinning should be used so that the mobile app and the API server know exactly which certificate public keys to expect from each other, protecting themselves from rogue certificates provided by man in the middle attacks used to decrypt the data in transit. Unfortunately, even Certificate Pinning can be bypassed with the use of instrumentation frameworks, so we must look further for a more complete solution.

Mobile App Identification

The most common way for a mobile app to identify itself to the API server is with the use of an API Key, a unique ID string present in the headers of each API call or as a query parameter in the URL. The latter method is not recommended since it may be logged in any server that handles the URL and then extracted.

Note: Read the client as the mobile app and the resource server as the API server.

API keys help identify the origin of a request and can be used to rate-limit the frequency of API calls. They provide all users of the app with the same set of access permissions and call statistics gathering. Typically, though, API keys are static secrets within an app which are vulnerable to discovery and abuse, and blacklisting a compromised key will disable not just one but all installed app instances.

User Authentication

The most common user identification approach is to use the OAUTH2 authorization flow that provides an access token, also known asa bearer token, in the form of an JWT token, consisting of a JSON payload containing a set of claims with an expiration time. The token must be signed by the OAUTH 2 provider with a secret that is shared with the API server. Per best practices, it should be passed in the header of each HTTPS request so that the API server can validate the signature and check that the claims have not expired.

Note: Read user agent as a browser, client as the mobile app, authorization server as the OAUTH2 provider, and resource server as the API server.

User access tokens often have long lifetimes — hours, days, or eve weeks in order to improve the user experience. This makes life easier for attackers to steal and reuse them frequently until they are detected and revoked.

Though using a user OAUTH 2 access token appears to be an improvement over using an API key, it still leaves a security risk within the mobile app, API, and backend server ecosystem. Simply put, it does not resolve the problem of the API server responding to requests from a cloned or tampered mobile app or from an automated script or bot. Additional techniques such as mobile app attestation are needed.

Mobile App Attestation

A mobile app attestation service uses unique characteristics of the mobile app to attest its integrity and authenticity. An example of a unique characteristic might be a simple hash of the application package. The integrity of this simple attestation depends on the integrity of the hashing computation. Such a simple scheme might befairly easy to spoof.

A more robust integrity attestation service might use a random set of high-coverage challenges to detect any mobile app replacement, tampering, or signature replay. If the responses satisfy the challenges, the mobile app attestation service returns to the mobile app a very time-limited integrity token signed by a secret that is known only by the attestation service and the API server. On failure, the mobile app attestation service will sign the integrity token with a random secret that is not known to the API server so that the server can distinguish between an integrity token that passed the challenges from one that failed to pass them or from one that was forged by an attacker while trying to reverse engineer the mobile app.

This means that with every API call, both the mobile app attestation token and the OAUTH 2 access token must be sent in the request headers in order for the API server to be able to validate both tokens, before handling the request.

Unlike the user authentication flow, the mobile app attestation service doesn't require user interaction. Thus, the token lifetimes can be extremely short, and no refresh tokens are needed as in a user authentication flow.

Crucially, once the mobile app attestation service has provided the integrity token that makes it possible for the API server to distinguish requests coming from a genuine mobile app, we have now effectively protected the OAUTH 2 access token from unauthorized reuse. We could also go further and remove all secrets in the mobile app and instead delegate to the API server the authentication of all calls to third-party APIs.

Mobile App Secrets

When the need to use secrets in a mobile app to access an API server or third-party service arises, those secrets commonly appear as plain text in the source code. More advanced developers use code obfuscation techniques to hide them while others calculate the required secrets dynamically at runtime and apply code obfuscation techniques to hide the related source code.

It should come as no surprise to anyone that any secrets or decision-making code that lives on the mobile device is at risk. In fact, any secret stored statically or calculated dynamically in a mobile app can be reverse-engineered by using techniques ranging from proxy tools to instrumentation frameworks to code decompilers.

While iOS developers may use the Keychain Services API to store the secrets in the encrypted database, Android developers will encrypt the secrets and save them in SharedPreferences, using at the same time the Android Keystore to keep the encryption keys safe. However, as described above, both iOS and Android solutions can be reverse-engineered at runtime.

A good approach is to delegate access management to an API Gateway of all third-party services that a mobile app needs to work with, thus removing the need for the app to handle all these different secrets. However, this still leaves the mobile app needing to store and present the required secret expected by the API Gateway; thus, an obvious exploit remains for attackers.

Considering the mobile app attestation service described earlier, it should be clear that employing such a technique will remove the need to have secrets in the mobile app source code or, if they are necessary for other reasons, at least to protect them more effectively.

Reverse-Engineering

The best way to know how to properly secure a mobile app is to think like an attacker would. The first step in that direction is to know what tools exist and how they can be used to reverse-engineer a mobile app to gain valuable insights on what the app's security strengths and weaknesses are.

Reverse-engineering may seem like a daunting task, one that is only achievable by a few, but, in fact, it is readily achievable by "normal" engineers due to the proliferation of open-source tools which were initially aimed at helping security researchers, pentesters, and whitehats to automate their tasks.

The use of a set of combined tools (like Apktool, Dex2Jar, and JD-GUI for Android or Clutch in conjunction with IPA or a Hopper disassembler for iOS) will allow an attacker to extract the source code from any mobile app binary for further analysis using a tool like TruffleHog to identify all secrets in the source code.

With a proxy tool like MiTMproxy, an attacker can intercept, observe, and manipulate the traffic between the mobile app and the API server in order to see how requests and responses are made, how they are structured, and what secrets are used.

If using an MitM proxy is not enough, then an instrumentation framework like Frida or Xposed will allow an attacker to run the mobile app on a device or emulator to intercept system or method calls and/or manipulate the memory of the device in order to understand how the code works, bypass security checks, or extract whatever sensitive data the attacker is interested in.

An all-in-one solution for reverse-engineering exists by the name of Mobile Security Framework. It only requires the mobile app binary to be uploaded — and then the process of extracting the source code, finding secrets, and potential security vulnerabilities is automated, and a very detailed report is given in the end. This tool can also be used while the mobile app is running to perform a dynamic analysis of what the code is doing and what traffic is going in and out, just like you would do with a discrete set of tools.

Summary

With the increase in mobile app deployment and the common practice of embedding secrets in the source code to access in-house and third-party APIs, mobile apps and their APIs have become an attractive target for attackers and a liability for the businesses that they represent in terms of security and attack surface.

The use of a secure communication channel in conjunction with mobile app attestation is a solid and complete solution to reduce the attack surface and strengthen the security between a mobile app and an API server, because if you're using only a secure communication channel with an API key, user authentication and code obfuscation techniques will not prevent the API server from being abused by other sources.

So, the takeaway is to develop mobile apps with security in mind from day one, minimizing the use of embedded secrets and delegating access management to an API Gateway as needed. While mobile attestation techniques significantly improve app and API security, the developer should continuously conduct reverse engineering tests to probe the security and resilience of the code he writes following practices recommended in the OWASP Mobile Security Testing Guide.

This article is featured in the new DZone Guide to Dynamic Web and Mobile Development. Get your free copy for more insightful articles, industry statistics, and more!