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 the app's data store
• Reverse engineering to locate vulnerabilities, embedded credentials, or key-generating algorithms
• Malware installation or blocking existing functions
• Access the device and control connections
• Etc.

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

Shielding in mobile applications: Why is it not common?

The main reason is that developers emphasize that these applications work correctly and on a wide range of devices, meeting 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 number of users who may use it.

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

Basic security measures for mobile applications

When we do our mobile development, 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 anticipating requirements for software architects and developers looking 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 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).

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

Storage of data and privacy

Protecting 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 this information are the following:

• Do not store sensitive information in the local storage of the device, 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 secure enough random number generator.

Authentication and Session Control

In order 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 are some requirements that we must take into account:

• Biometric authentication, if any, is not associated with events (e.g. using an API that simply returns "true" or "false"), but based on unlocking the keychain/keystore (secure storage).
• For applications that handle 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 security in communication with the server, guaranteeing the confidentiality and integrity of the exchanged data. To achieve 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 accepts certificates signed by a trusted CA.
• The application uses its own certificate store or performs certificate pinning or public key pinning.

Interacción con la plataforma móvil

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 these mechanisms are properly protected
• Disable JavaScript in Webviews unless necessary.
• WebViews are configured to allow only the minimum of schemes (ideally, only https). Dangerous schemes such as file, tel, and app-id are disabled.

Code Quality

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

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

Measures against tampering and reverse engineering

We must prevent an attacker from manipulating our application or reverse engineering the code. To achieve this, there are several mechanisms that must 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 exists, 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 later modified use. To achieve this, it is verified that the application's signature is original and checksum verification mechanisms are applied.
• Code obfuscation: Code obfuscation allows to compress, optimize and make the code unreadable by renaming classes, fields, methods and names semantically. The result is a smaller application that is more complex to reverse engineer, making it difficult for malicious eyes to understand them.
• Verification of the installer's origin: With this technique, it is checked that the application has been distributed from a trusted source, avoiding having a copy of the apk on our device that may have been infected with malware.
• Anti-Debug: Anti-debug techniques make it difficult to debug an application, in order to apply certain actions that prevent an attacker from continuing the process. The simplest mechanism is through a property in the app's manifest itself, although it is recommended to dynamically check in several points if debugging is taking place or not.
• Anti-Emulator: If our application is running on an emulator outside 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 system and application reserved memory, compromising data persistence and therefore data privacy.
• Anti-Clone: mechanism to prevent the application from being cloned, in this regard the 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) that allows evaluating if the Android device running an application is reliable.

Conclusion

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

"Being aware of vulnerabilities is already half of security".