Avoid Mobile Application Security Pitfalls -1

Overview

Key Challenges

Mobile application security failures lead enterprises to sensitive data loss, exposure of infrastructure, fraud and noncompliance.

The architectural decisions made very early on in the process will determine many of the limitations in the security functionality available to security leaders.

Mobile applications are subject to new types of attacks and require developers to revisit, learn and reprioritize security best practices.

When seeking advanced mobile application security functionality for particularly sensitive apps, the landscape is fragmented, maturing and technically challenging to grasp.

Analysis

Identify the Risks for Your Mobile Applications

Sensitive data loss — Applications that lack adequate protection can allow attackers to obtain sensitive data that may reside in these applications, such as payment credentials and intellectual property. Some threat vectors can be device theft or loss, malware on the device and man in the middle over unsecured networks.

Exposure of infrastructure — Mobile applications need to communicate with enterprise back end services. This requires the enterprise to expose internal resources, such as an API or enterprise databases. If uncontrolled, this exposure can lead to a number of attacks, such as API scraping and denial of service.

Fraud — This risk is particularly accentuated in financial services and retail applications, and wherever a mobile application includes financial transaction functionality where payment credentials are expected to be exchanged. The techniques attackers use include repackaging, SMS grabbing through malware, script injection and overlay attacks.

Compliance — Noncompliance with specific regulations may lead to fines.

Choose the Right Architecture

Before looking at the architectural options, an initial consideration would have

to do with whether the app is published onto a commercial app store or distributed through enterprise distribution. For consumer-facing apps, the choice will be obvious, less so for workforce and partner-facing applications. Privately distributed apps will be less subject to attacks such as reverse engineering, and they will allow somewhat more visibility over the device. In addition, there are various options to deploy and impose security controls, among which are application management via UEM and stand-alone application management solutions.

There are three main architectural options with mobile application development options available today: native, hybrid or pure web-based app. To these three categories, we would add PWAs, which are still emerging. Each architectural option leads to different security considerations and there will be different trade-offs that will need to be made between security and performance.

For instance, while it is fast and easy to convert an enterprise web application into a mobile web app, the cached content of the application will be difficult to encrypt effectively. If the cached content is minimized and deleted too frequently for security purposes, this will impact the speed of the app and its user experience. Securing the app may prove to be lengthier and more expensive, and the architectural decision might need to be revisited.

A related consideration has to do with device and server-side checks. Security checks performed on the device can be bypassed by an attacker by manipulating the device or the app. For example, on a jailbroken or rooted device, an attacker can bypass native integrity check protections. For certain apps, it might be more suitable to put in place server-side controls, while other use cases may require dedicated on-device protection (refer to the When Needed, Go Beyond the Basics section for this last kind of functionality).

Native development provides access to all the native security capabilities of the iOS and Android platforms. Native applications are also known to offer a better performance since they use native APIs from the OS. Android and iOS have documentation available on best practices developing in the respective environments natively. Both native environments offer security functionality that can cater to basic needs, such as authentication and encryption, but also advanced ones like device attestation14 and storage of credentials within trusted environments. On the other side, native development will require to maintain at least two separate versions of the application.

For highly competitive app categories, the organization may be obliged to go with a native architecture. In other cases, hybrid architectures can represent a compromise between security and usability (or the usage of cross-platform frameworks such as React Native, Xamarin and Flutter). With hybrid applications, sensitive operations can be conducted with native functions, and the presentation can be delivered using web architecture based on HTML5.

An added challenge is that often mobile apps are built and delivered independently through a business unit, without IT support or security involvement. To ensure they are involved, security leaders must communicate their policy to the various lines of businesses. Visibility into MX platforms, security champions and application discovery tools are all helpful instruments in this effort.

Secure the Mobile Application

Secure application development principles do not change within the mobile domain. However, mobile apps move at least a portion of the software logic onto a mobile device. This means certain application security best practices need to be particularly emphasized. 

Do Not Hardcode Credentials

Mobile app developers tend to hardcode credentials in the app while developing. Rather than the more obvious authentication credentials for the user to authenticate to the application, here we intend authentication credentials for services used by the application. For example, when the app interacts with a third party, API developers will use their own authentication credentials. An attacker can obtain and use those credentials, especially if they are privileged ones, to steal data from an API. The app should authenticate to the API instead.

Minimize App Permissions

Permissions empower apps, but this also opens the door to a number of risks. A legitimate app with unnecessary permissions is not only a privacy and compliance hazard, but it can also become a target for attackers. By default, an app should not require any device permissions. When necessary to conduct specific functions, permissions should be added selectively. Because most developers reuse existing libraries to develop, their apps end up asking for many more permissions than what they really need. SRM leaders should ensure the libraries used are of good quality and do not request permissions that they do not use.

Protect Sensitive Data

A common pitfall in mobile is storing sensitive information within the app without proper protection.18 Attackers can reverse engineer the code and steal this information. Access credentials and encryption keys should be safely stored, if they must reside on the device. Both iOS and Android provide dedicated storage for credentials and sensitive data, called Keychain and Keystore, respectively, which can be accessed through native functions. An alternative can be to minimize the sensitive data residing on the device. However, as mentioned, these decisions should be taken by evaluating the impact on performance that client-to-server interaction may require. A more complex alternative to using native key storage is white-boxing mechanisms, discussed in the When Needed, Go Beyond the Basics section.

In addition to using encryption, the app should be able to wipe its data via a remote command to cater for device loss.

Use Certificate Pinning Where Possible

Because they are used on the go, mobile apps connect from unsecured networks more frequently than web applications. Certificate pinning is a technique to counter man-in-the-middle attacks that could take place over such networks. There is some controversy around the usage of certification pinning, and the advice to use it comes with some caveats: NDR tools may

not be able to work, as traffic inspection is harder to do. Also, some browsers may not support certificate pinning, which makes it a challenge for hybrid apps.