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
Recently, IBM has published research showing the 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 hacker 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. 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 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
Last year, 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.
Below graphic shows the number of data breaches and records in the United States since 2005.
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.
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.
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.
#2 Implement HTTPS – 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 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.
#3 Optimizing Data Caching
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.
#4 Protect Local Storage Data
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.
#5 Preventing Client-side Injection for Mobile App Security
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:
- Harmful data will be supplied using “%@” instead of a proper parameterized query “?”.
- Using libXML2 over NSXMLParser
- As much as possible, avoid using Old Objective-C functions vulnerable to Injection
- While using content providers or dynamic queries – make sure that you are using parameterized queries.
- Remove file system access for WebViews.
- Validate data and actions for intent
#6 Deploy Anti-tamper Techniques – 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 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
#7 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 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.
#8 High Security for Native Application
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
#9 Implement the Principle of Least Privilege
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.
#10 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 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!