Mobile Application Security: Checklist for Data Security and Vulnerabilities

“It takes 20 years to build a reputation and a few minutes of cyber-incident to ruin it.”
― Stephane Nappom, Cyber Security Consultant

Truly said.

Recently, IBM has published research showing evidence that attackers can misuse Apple’s Siri shortcuts for their wrong intentions. If these shortcuts are not configured properly, it will send the details to hackers including photos, videos, IP addresses, and more.

According to CIO Magazine, one-third of all iOS enterprise applications are vulnerable to attackers. The situation is even worse for Android. In the world of mobile apps, cybersecurity threats are now evolving even faster along with emerging technologies like IoT; increasing the Cyber Security skill gap further.

As mobile applications continue to provide niche services to users worldwide, mobile fraud has grown simultaneously over time. As a result, it has pushed organizations to take mobile application security more seriously and devise fool-proof strategies for their applications. 

So, what is mobile application security? 

It is the practice of protecting mobile applications and safeguarding users’ information from fraudulent attacks, including tampering, malware, reverse engineering, keyloggers, hacking, and other forms of criminal manipulation. By adopting a robust mobile application security strategy, organizations can ensure data integrity and protect sensitive information from falling into unauthorized hands. 

With multiple operating systems and distributed nature of components, Enterprise application security remains one of the most difficult to solve puzzles from the last decade. Some common mobile security exploits affecting enterprise applications are:

• Malware applications on user’s device exploiting other mobile applications
• Botnet attacks to extract user information and keystrokes
• Vulnerabilities in servers, integrated browser, and third-party libraries
• Weak authentication and authorization
• Hard-coded credentials and deployment in debugging mode
• Injection flaws, such as SQL injection, LDAP injection, and CRLF injection
• Security Misconfiguration
• Insecure deserialization flaws
• Cross Site Scripting (XSS)
• Sensitive Data Exposure

In 2017, Air Canada was a victim of mobile application data breach that affected 20,000 users. In that case, attackers had got access to all personal information including passport number, insurance details, and more. Fortunately, the company was able to protect the credit card details of customers.

It’s just an example.

The below graphic shows the number of data breaches and exposed records in the United States from 2005 to 2020.

Implementing application security starts right from planning, and then relies on how faithfully the security guidelines have been followed throughout the software development life cycle.

In order to build a strong wall of defense for mobile applications, it is important to understand the common vulnerabilities that can potentially affect them.

What are the common vulnerabilities in mobile applications?

These are the top 5 common vulnerabilities in mobile apps from the OWASP list that you must look out for:- 

• Insufficient binary protection 

A lack of binary protection exposes attackers to sensitive information like intellectual property, credentials, and more. In addition, hackers can access passwords, API keys, and business logic with reverse engineering in such cases. 

• Lack of server-side controls 

Developers must build mobile applications that can prevent unauthenticated access on the server-side as a best practice. They should verify the server input data when the application processes and halt any suspicious behavior immediately. Also, both the app and server must use encryption while transmitting and receiving data. 

• Unsafe data storage 

If the data is not securely stored, it can lead to severe consequences such as identity/credential theft or fraud, damaging the organization’s reputation. Therefore, such sensitive data should be stored in keychain pairs and appropriately encrypted to avoid misuse. 

• Inadequate authentication/authorization 

Suppose an application fails to perform the necessary authorization checks that verify a function or data accessibility that the users intend to perform. In that case, it allows attackers to bypass authentication protocols to access sensitive data. A secure authentication system that handles requests on the server-side is a good practice to ensure secure data access.

• Poor session expiration 

Mobile applications often provide long-user sessions or non-expiring sessions to make the app more user-friendly. However, it invites attackers to gain access to the session and recover the transaction information. Therefore, a proper session handling system with high entropy and unpredictable session tokens is vital for any mobile application. 

So, what are the security considerations for mobile applications?

We created this exhaustive list of common mobile application security checklist that you can use to reduce the number of vulnerabilities present in your application:

• Evaluate Open Source Codes or Third-party Libraries
• Implement SSL/TLS Security Layer
• Optimizing Data Caching
• Protect Local Storage Data
• Preventing Client Side Injection
• Deploy Anti-tamper Techniques – Reverse Engineering
• Enabling Remote Data Wipe and Device Locking
• High Level Security for Native Application
• Implement the Principle of Least Privilege
• Authorization using OAuth 2.0

#1 Evaluate Open Source Codes or Third-Party Libraries

Open source is changing our world, speeding up development and deployment. In certain cases, we have seen enterprises applications containing as much as 90% open source codes which is both good and bad at the same time.

While rapid software development promotes using open source codes, most developers incorporating a third-party code won’t log this information. When integrated with millions of lines of code, this third-party code often goes unnoticed, untested for security.

In 2017, due to a third-party code involved, more than 1400 vulnerabilities were introduced into ColdFusion’s Pyxis supply station. Most of these vulnerabilities allowed attackers to exploit the system remotely.

We insist on keeping a security policy that any 3rd party or open-source code being added has to go through exhaustive security testing to ensure that deployment of this code in the production environment won’t make the application vulnerable.

One should also remain updated with CVE’s dictionary to keep in touch with common known security vulnerabilities in open-source tools.

The network connection between the mobile application and server, if not secured properly is prone to man-in-the-middle-attack. The validating authenticity of security certificates helps to eliminate illegal access by attackers.

Always make sure that your application’s code acknowledges valid security certifications and blocks any request with invalid self-signed-certificates.

Here’s a presentation by OSWAP on using certifications with mobile applications, understanding the pros and cons associated with using certificates:

You have to make sure that the certificates are valid, and here are some ways you can do it:

• You need to extract the strings from the certificates and do remember that strings have byte length representation followed by numerous bytes and some have unique encoding like UTF-8 so never assume that the string is null-terminated.
• Mobile devices facilitates real-time-sync with applications. You should confirm the “notBefore” time and “notAfter” time in the certificate and match it with the device’s time.

If any specific policy is in place, make sure it reflects in the certificate policy extension, and the mobile application is able to acknowledge it.

We built a secure mobile application for CrayPay by implementing tokenization to encrypt user card information and turn it into unidentifiable numbers. Furthermore, we added a few more security features, such as storing the hardware device information to avoid multiple signups.

Mobile devices often store cached data to enhance the app performance, which makes it more vulnerable because attackers could easily breach and decrypt the cache data to steal user’s account information.

If the nature of data that your app stores is extremely sensitive, having a password to access the application reduces vulnerabilities associated with cached data.

Further, automatically wiping cache data every time the device reboots or logs in through a private network reduces cache related mobile application security concerns.

While you may not be keeping patient records locally, but there’s a 90% chance that you store some information locally that can help an attacker gain access to almost anything.

There’s a huge difference in how iOS and Android applications store data locally. Let’s have a look at the iOS ecosystem as an example.

iOS applications primarily store data by using:

• NSUserDefaults – One of the most common ways to store data by applications on iOS
• Plist files – Store various settings and configuration related information
• CoreData and SQLite files – Core data Generalizes and automates solutions to common task related to data storage and management
• Keychain – Encrypts data before even saving it within keychain

Let’s break these storage methods step by step.

The security issues concerning their usage:

• NSUserDefaults keeps information stored even after a user closes the application and restarts it.
• Any information stored within plist files isn’t encrypted and creates a concern with jailbroken devices.
• Any information stored in CoreData is not encrypted and can easily be retrieved.
• Keychain is one of the best ways to store data locally, but given no straightforward implementation, in a quicker go-to-market environment, it usually is ignored.

Whether it is iOS or Android, your choice of local data storage implementation should be based on strict and thorough security considerations. In the case of Hybrid applications, things further complicate.

Make sure you don’t allow your application to store any sensitive data in local storage, credit card details for example.

Under client-side injection, attackers push malicious code in the form of input, which then is consumed by the mobile application. This happens on account of weaker input validation and lack of mobile security testing policies.

In most enterprises, mobile application security primarily includes testing to validate if a user can sign-in using the right credentials, but testing for this authentication to fail is often ignored. To many, input validation is boring and not very cost effective, and hence it usually takes the backstage.

To reduce the chances of a client-side injection, as a basic guideline one should look into:

• Data stored on the device
• User sessions
• Mobile application interfaces

SQLite is one of the most common forms to store mobile application data and is very well known to SQL injection exploits. These exploits are so well known that there even exists an SQLiteSQL injection cheat sheet.

Dealing with iOS and Android Injection isn’t very difficult, you need to make sure:

In iOS:

• Harmful data will be supplied using “%@” instead of a proper parameterized query “?”.
• Ensure that UIWebViews(Javascript injection) do not execute without proper input validation
• Using libXML2 over NSXMLParser
• As much as possible, avoid using Old Objective-C functions vulnerable to Injection

 In Android,

• While using content providers or dynamic queries – make sure that you are using parameterized queries.
• Javascript Injections
• Remove file system access for WebViews.
• Validate data and actions for intent

Tampering with your application has several benefits for the attackers: Authentication bypass, geolocation falsification, stealing sensitive data and many others. It can then be leveraged to get access to offline documents, location falsification, payment and medical related sensitive information.

As you can see, it isn’t simply tampering, it is almost similar to having a back door within your IT infrastructure.

Implementing run time security should be at the top of the priority list for most enterprises building next generation mobility strategy – especially for those building consumers facing applications.

What happens when an attacker accesses runtime to manipulate your application?

Any attacker accessing runtime can replace your default application implementations and change it to something that favors exploitation.

For example, an attacker can get an insight into the internal workings of the application and modify the control flow or internal code structures to influence application behavior.

This can have significant consequences for the application; some example use cases like cryptographic key extraction, financial data leakage, interrupting server connection.

While prioritizing various security models involved in building enterprise applications consider the following scale of security:

Native OS security model < App signing < Code obfuscation < Static integrity checks < Advanced custom cryptography < Dynamic integrity checks

The capability to remotely wipe and lock sensitive data from a user’s device gives an additional layer of security to enterprises. While there are many existing tools that enable remotely wiping data, they have their own pros and cons.

Consider these two cases:

• Isolation of enterprise data from the user’s personal data in case of BYOD scenario
• Data breaches in case of a stolen or lost device

To enable remote data wipe, enterprises use the following solutions depending on the device ownership models:

• Factory reset wipe – Allows business administrators to erase the device settings, cache, user data and third-party applications from the device (from the flash memory and even the removable storage. This process is reasonably easy, but it might not be the best option as it doesn’t wipe the data from garbage collection and can be recovered. Microsoft Intune offers enterprise remote data wiping service through their Azure Intune platform, which you can find here.
• Full device wipe – This process only overwrites the keys used for device encryption rather than overwriting the entire device storage.
• Enterprise device wipe – When you set device wipe as your enterprise security solution, you selectively get to remove your business specific content from the device, without deleting user’s own personal information. This fits perfectly with the BYOD paradigm. Blancco, Radia Endpoint are some notable enterprise tools in this space.

Securing mobile devices is also as critical as securing your application layer. Building native security measures specific to iOS and Android platform adds another layer of security to your application.

iOS and Android native security:

• The application sandbox – Preventing applications from accessing locked parts of memory that don’t belong to the application
• Code signing – App Authorization and identification
• Entitlements and permissions – Restricting access to devices features, ability to run in background
• ASLR – Helps to randomize data in RAM to prevent exploits from taking control of the application.
• Full disk encryption – Encrypting user’s personal data on the device’s internal storage

As mentioned in The Principle of Least Privilege, the app should allow performing the code with minimal permissions and no more. To cite an example, if the function in your app doesn’t require to access user’s photos, then you must not.

Implementing this principle will help in decreasing the chances of mobile application security threats.

Nearly everyone working in enterprise production systems has worked, or, is working with some form of OAuth implementation like:

• Authorization in server-to-server communication
• Authentication using certificates between servers
• SSO across multiple applications
• Authorization of B2B integration

But there have been mixed reactions around the usage of OAuth with enterprises. The recent talks about a possible breach on OAuth well illustrate this situation. Most enterprises fail to understand the usefulness of OAuth, and either go all in or don’t use it all.

An introduction of OAuth 2.0 for your enterprise application security has to be incremental rather than a full-fledged implementation. Following an incremental implementation model, enterprises remain in control of their security layers.

Source: Digital Ocean

Note that there are many customized API implementations of OAuth, each may have their own implicit grants and security settings, requiring a close inspection before implementation.

Another good idea to improve security with OAuth 2.0 is to utilize OpenID connect along with it. There are extensive guides on setting up Oauth2 for Android and iOS applications – Here’s for Android, and for iOS application check this.

Don’t forget: Ensure you monitor and test the security concerns of application on timely. Not monitoring the activities happening on the application can be the reason of data breach too.

Businesses these days are fighting on all fronts to secure their applications and infrastructures. It is critical to remain constantly updated when it comes to enterprise application security. This checklist is a primer to guide your enterprise examining mobile application vulnerabilities.

Have any thoughts or stories to share about mobile application security? Feel free to share in comments!