The Open Web Application Security Project (OWASP) has been working towards categorizing, evangelizing, and publishing remediation information for web application security for 12 years. The OWASP Top 10 Project started in 2007 when they released a list of the top 10 most prevalent web application vulnerabilities in order to help educate developers and testers. Ever since, the “OWASP Top Ten” project has been a huge success.
In early 2012 OWASP realized that the application landscape had shifted. That’s when the Top 10 list for mobile applications was started. Last week, we wrote about the most prevalent of the Top 10 Mobile risks, i.e. Weak Server Side Controls. This week, we talk about the second most exploited threat in mobile applications, Insecure Data Storage.
What is Insecure Data Storage?
The title says it all, insecure storage of data. Many developers assume that storing data on client-side will restrict other users from having access to this data. Interestingly, most of the top mobile application security breaches have been caused by insecure or unnecessary client-side data storage. File systems on devices are no longer a sandboxed environment and rooting or jailbreaking usually circumvents any protections.
Am I Vulnerable to Insecure Data Storage?
In order to answer this, one needs to understand what different types of data are there and how are these stored insecurely.
Data – Usernames, Authentication tokens or passwords, Cookies, Location data, Stored application logs or Debug information, Cached application messages or transaction history, UDID or EMEI, Personal Information (DoB, Address, Social, etc), Device Name, Network Connection Name, private API calls for high user roles, Credit Card Data or Account Data, etc.
Places OWASP most often sees data being stored insecurely include the following:
- SQLite databases
- Log Files
- Plist Files
- XML Data Stores or Manifest Files
- Binary data stores
- Cookie stores
- SD Card
- Cloud synced
How Can This Affect Me?
In the event that an adversary physically attains the mobile device, the adversary hooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. An adversary may construct malware or modify a legitimate app to steal such information assets.
Business Risk: Insecure data storage vulnerabilities typically lead to the following business risks for the organization that owns the risk app:
- Identity Theft
- Reputation Damage
- External Policy Violation (PCI)
- or Material Loss.
How to Prevent Insecure Data Storage?
Well, the basic rule for mobile apps is not to store data unless absolutely necessary. As a developer you have to assume that the data is forfeited as soon as it touches the phone. You also have to consider the implications of losing mobile users’ data to a silent jailbreak or root exploit.
Here are some best practices that OWASP recommends:
iOS Specific Best Practices:
1. Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements.
2. Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto. However, for particularly sensitive apps, consider using whitebox cryptography solutions that avoid the leakage of binary signatures found within common encryption libraries.
3. If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which as stated above is trivial in some cases.
4. For databases consider using SQLcipher for Sqlite data encryption
5. For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters.
6. For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely be used (see NSData Class Reference for protection options).
7. Avoid using NSUserDefaults to store sensitive pieces of information as it stores data in plist files.
8. Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.
9. Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.
10. Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.
Android Specific Best Practices:
1. For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”
2. For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.
3. Ensure any shared preferences properties are NOT MODEWORLDREADABLE unless explicitly required for information sharing between apps.
4. Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.
5. Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.
In this article, we discussed about what Insecure Data Storage can do to your customer data as well as your business reputation. Hope this helps you in being careful and building more secure apps. Next week, we’ll continue the journey of understanding the Top 10 Mobile threats.
If you would like more information on assessing your apps, I recommend you to try our cloud based offering, Appknox. Our scanner will help you identify risks associated with your mobile app quickly and easily. Moreover, our team of security experts can help you fix them easily as well.