Mobile application security: How to ensure it?

What are attackers looking for in our mobile devices?

• Access to credentials
• Personal data (addresses, credit card information, location…)
• Access to the application's data storage
• Perform reverse engineering to locate vulnerabilities, embedded credentials, or key-generating algorithms
• Install malware or block existing functions
• Access the device and control connections
• Etc.

As we can see, equipping our application with security mechanisms that prevent the aforementioned actions becomes essential.

Shielding in mobile applications: why is it not common practice?

The main reason is that developers emphasize that these applications work correctly on a wide range of devices, meet all defined requirements… and focus mainly on aspects more attractive to the user such as usability, user experience, and graphical interface.

However, it is essential that we are aware that implementing security mechanisms in a mobile application is equally important, especially considering the large volume of users who may use it.

In fact, more and more companies are requiring their applications to undergo a process of ethical hacking, which involves hacking a system to identify and repair potential vulnerabilities, effectively preventing exploitation by malicious hackers.

Basic security measures for mobile applications

When we develop our mobile application, we must focus on several areas and meet a series of requirements in each of them. To do this, we can rely on the OWASP Mobile Application Security Standard, which is responsible for providing requirements for architects and software developers who seek to develop secure mobile applications.

This guide defines 2 levels of security verification, as well as a set of requirements for resistance to reverse engineering.

The choice of the level will depend on the context of our application. Level L1 contains generic security requirements recommended for all mobile applications. The next level, L2, is focused on apps that handle highly sensitive data (financial sector, healthcare industry).

Below we specify the most notable security requirements that we should take into account in the development of our application, categorized into seven areas, although the complete list can be found in the OWASP guide itself:

Data Storage and Privacy

The protection of sensitive data, such as credentials and private information, is not only a legal imperative but also a critical aspect of mobile security.

Some of the requirements that help prevent access to such information are as follows:

• Do not store sensitive information in the device's local storage, and if necessary, it must be encrypted using a key derived from the secure storage hardware, which requires prior authentication.
• Do not write sensitive information in system logs or backups.
• Do not expose sensitive information such as passwords or card numbers through the UI (user interface) or screenshots, and disable keyboard cache in text fields containing such information.

Use of cryptographic keys

When it comes to protecting sensitive information stored on our device, cryptography is a fundamental component. When using cryptographic keys, we must take into account the following requirements:

• Do not rely solely on symmetric cryptography whose keys are directly in the app's source code.
• Do not reuse the same cryptographic key for multiple purposes.
• Random values are generated using a sufficiently secure random number generator.

Authentication and session control

For an application to be secure, it must have an authentication mechanism and user session control. While it is true that most of this logic is on the server side, below we indicate some requirements that we must take into account:

• Biometric authentication, if available, is not associated with events (e.g., using an API that simply returns "true" or "false"), but rather based on unlocking the keychain/keystore (secure storage).
• For applications that manage very sensitive information, apply two-factor authentication mechanisms.
• Sessions and tokens must expire after a predefined period of user inactivity.

Communication with services

An important aspect in apps is to ensure the security of communication with the server, guaranteeing the confidentiality and integrity of the exchanged data. For this, some requirements are:

• The information is sent encrypted using the TLS protocol.
• The application verifies the X.509 certificate of the remote system when establishing the secure channel and only certificates signed by a trusted CA are accepted.
• The application uses its own certificate store or performs pinning of the server's certificate or public key.

Interaction with the mobile platform

The interaction between applications and operating systems must be carried out taking into account the following aspects:

• The app requires the minimum necessary amount of permissions.
• The application does not expose any sensitive functionality through IPC mechanisms unless such mechanisms are properly protected
• Disable JavaScript in Webviews unless necessary.
• WebViews are configured to allow the minimum of schemes (ideally, only https). Dangerous schemes like file, tel, and app-id are disabled.

Code Quality

Although apps are not as vulnerable to Cross-Site Scripting attacks, developers should follow a guide of best practices to ensure the code is secure:

• The application must be signed and provided with a valid certificate, as well as being published in release mode.
• The application properly captures and manages potential exceptions.
• The free security features of the tools, such as byte-code minification, stack protection, PIE support, and automatic reference counting, are enabled.
• Make use of tools that allow analyzing the source code to detect possible vulnerabilities such as SonarQube.

Mechanisms against tampering and reverse engineering

We must prevent an attacker from being able to manipulate our application or perform reverse engineering of the code. To do this, there are several mechanisms that should be implemented:

• Application signing: One of the most important security techniques in Android is signing applications using public and private keys.

When compiling an application with all its components (texts, graphics, code...), each developer must secure it with their certificate so that the signature identifies the application and it is possible to know if it has been modified or remains intact. This is the only way to know if an app is fake or authentic: if the signature has been modified, if it has one, it will not correspond to the original developer.

• Anti-Tamper: Anti-tamper techniques make it difficult for an attacker to modify software by performing reverse engineering and validating its integrity for subsequent modified use. To achieve this, it is verified that the application's signature is the original, and checksum verification mechanisms are applied.
• Code obfuscation: Code obfuscation allows for compacting, optimizing, and making the code unreadable by semantically renaming classes, fields, methods, and names. The result is a smaller application that is more complex to reverse engineer, making it difficult to understand for malicious eyes.
• Installer origin verification: This technique ensures that the application has been distributed from a reliable source, preventing us from having a copy of the apk on our device that may have been infected with malware.
• Anti-Debug: Anti-debug techniques hinder or detect the debugging of an application, with the aim of applying certain actions to prevent an attacker from continuing the process. The simplest mechanism is through a property in the app's own manifest, although it is recommended to dynamically check at various points whether debugging is taking place or not.
• Anti-Emulator: If our application is running on an emulator outside of the development process, it indicates that someone other than us is trying to analyze the application. Therefore, a good practice is to check that in a release version, the application is not being accessed through an emulator that facilitates attacking its security.
• Anti-Root: It should always be avoided whenever possible for an application to run on rooted devices, as they are much more vulnerable and allow access to the reserved memory of the system and the application, compromising persistence and therefore the privacy of the data being handled.
• Anti-Clone: mechanism to prevent the application from being cloned; in this regard, appropriate properties will be defined to prevent making a copy of the installed application and obtaining the binary that a potential attacker could use to apply reverse engineering techniques.
• Reliable device: Google has an anti-abuse API (SafetyNet Attestation API), which allows evaluating whether the Android device on which an application is running is reliable.

Conclusion

Every day we use more mobile applications and they store an increasing amount of sensitive user information. Therefore, it is very important to stay updated on new security measures that emerge and apply them proactively to our developments. The goal should not only be for the user to interact with a good UX, but also to do so with complete security.

“Being aware of vulnerabilities is already half of security”.