Mobile application security: Checklist for Data security and vulnerabilities

Shares

Mobile application security: Checklist for Data security and vulnerabilities

Mobile Application Security (2)

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

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

  • Malware applications on user’s device exploiting other mobile applications
  • Botnet attacks to extract user information and key strokes
  • Vulnerabilities in servers, integrated browser, and third-party libraries
  • Weak authentication and authorization
  • Hard-coded credentials and deployment in debugging mode  

Last year, TeamViewer was a victim of such an attack, and, thousands of users reported that someone was trying to make a purchase with their credit cards. Fortunately, TeamViewer was able to recover their server within a few hours.

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

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

Mobile application development security checklist

Evaluate open source codes or third party libraries for Vulnerabilities

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 line of code, this third party code often goes unnoticed, untested for security.

Last year, 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 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.

Authorization using OAuth 2.0  

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 has 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.

Preventing client side injection for mobile app security

Under client side injection, attackers push malicious code in 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 parametrized queries.
  • Javascript Injections
  • Remove file system access for WebViews.
  • Validate data and actions for intent

Optimizing data caching for application security

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 passcode 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.

Disable debugging before the release

Many developers don’t turn off debugging when they deploy their application in product environments. Keeping debugging on in production environments allow attackers to gain access to the intrinsic working of critical parts of your application.

Turning off debugging mode is extremely simple, in fact, this, in reality, is just a deployment prep checklist, a developer can turn off debugging mode by:

  • Debuggable = ‘false’ in case of Android
  • PT_DENY_ATTACH in case of iOS applications

Anti-tamper techniques for data integrity and to prevent application modification, reverse engineering 

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 consumer 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

Protect sensitive information that application stores locally

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 – Stories 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 straight forward 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.

Enabling remote data wipe and device locking

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 wipeAllows 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 wipeWhen 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.

Implement SSL/TLS security layer

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 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.

Native application security for mobile device and network

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

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 application security? Feel free to share in comments!

Jignesh Solanki

A thought leader, Jignesh leads Simform's Product Engineering team by DevOps Institutionalization, end-to-end product development and consulting led transformation programs.

Join 1,000+ Industry practitioners who get mobile engineering insights from us!

Get our latest mobile application engineering insights and reports delivered directly to your inbox

You have Successfully Subscribed!