Apply These Best Practices to Secure Android and iOS Mobile Apps

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!

In the race to develop and evolve mobile apps with rich user experience, security can sometimes be left in the dust. A staggering 85% of some 45,000 mobile apps available in the Google Play™ and the Apple®App Store® violate at least one or more of the OWASP Mobile Top 10, according to a NowSecure benchmark analysis. That figure attests to the importance of incorporating mobile app sec best practices and automated testing into the development process.

Mobile apps provide several potential attack vectors for hackers to exploit. The most prevalent and common vulnerabilities arise from failing to secure data at rest (DAR) or data in motion (DIM) over the air. This can lead to stolen credentials, leaked company secrets, privacy violations, and more. What follows are some recommendations for how developers can create more secure Android and iOS mobile apps by safeguarding stored data and properly validating SSL/TLS certificates.

Insecure Data Storage

In our experience, user and application data is frequently stored insecurely. The best way to avoid data compromise is to refrain from storing or caching data on the mobile device. However, that practice isn’t always feasible. One option for minimizing the storage of user or app information is to transmit and display data, but not to persist to memory. This requires developers to ensure that a leak doesn’t occur when screenshots are written to disk. Another technique for reducing risk is to only store data in RAM temporarily.

Consider adopting some of the following additional best practices for storing data.

Properly Protect User Credentials

Never, ever store a password in plain text on a device. If it must be stored, create a hash value using a unique device token stored on registration. The reason to use a hash and device token is to avoid storing the actual username or password locally or loaded into memory unprotected. Even if it was copied to another device or posted on the web, it wouldn’t be usable. A malicious threat actor would need to uncover more information in order to successfully access the authenticated username.

Add Third-Party Encryption

If storing sensitive data on the device is an application requirement, add an additional layer of verified, third-party encryption such as SQLCipherto the data. Device encryption alone is not sufficient. Adding another layer of encryption provides more control over the implementation and attacks focused on the main OS encryption classes.

Encrypt highly sensitive values in an SQLite database using SQLCipher, which encrypts the entire database using a PRAGMA key. Generate thePRAGMA key at runtime when the user installs/launches the application for the first time. Generate a unique PRAGMA key for each user or device. The source of the key material must have sufficient entropy. For instance, don’t choose something that’s easily predictable such as a username or something else that can be guessed.

Watch External Storage

Don’t ever store user or app data in an Android external storage (SD)card. Prior to API 19, any app can read external storage. Post-API 19(KitKat), apps require READ_EXTERNAL_STORAGE permission.

Apps with this permission can access any data on external storage without further permission management. If you need to store app data in this manner, protect it by setting proper file permissions to avoid unauthorized read/write access.

If an app requests data from external storage, developers must use scoped directory access via the StorageManager class. This enables users to only grant access to a specific directory from external storage that’s specified by the developer. For example, an app may only need photos taken with the native camera app. A user could grant the app with access to the pictures directory, but not the entire SD card.

StorageVolume volume = (StorageVolume)
 mediaMountedIntent.getParcelableExtra(StorageVolume
EXTRA_STORAGE_VOLUME);
volume.createAccessIntent(Environment
DIRECTORY_PICTURES);
startActivityForResult(intent, request_code);

Use Keychain Carefully 

iOS provides the Keychain for secure data storage. But in several scenarios, such as when a device has been jailbroken, the keychain can be compromised and subsequently decrypted. And in iOS 10.3 API and below, items added to the Keychain will remain in the Keychain even after the app has been uninstalled.

Choose the Most Restrictive Protection

When storing data in the Keychain, use the most restrictive protection class as defined by the kSecAttrAccessible attribute that still allows your application to function properly. For example, if your application is not designed to be running in the background, use kSecAttrAccessibleWhenUnlocked or kSecAttrAccessibleWhenUnlockedThisDeviceOnly.

• To prevent the exposure of Keychain data via iTunes backup, use the “ ...ThisDeviceOnly ” protection classes whenever possible.

• For highly sensitive data, supplement Keychain protections with application-level encryption. For example, require the user to enter a passphrase to authenticate within the application, then use that passphrase to encrypt data before storing it in the Keychain.

Insecure Data Transmission

The second major attack vector comes from data in motion that hasn’t been fully secured. In particular, potential problems arise from the lack of TLS/SSL certificate validation. Many apps don’t properly validate SSL/TLS certificates, leaving them vulnerable to man-in-the-middle attacks. 

Two common mistakes around certificate validation can lead to man-in-the-middle (MiTM) attacks. The first stems from accepting self-signed certificates. Developers may disable certificate validation in apps for a variety of reasons. For example, a developer may need to test code on the production server, but lacks a domain certificate for the test environment. In this situation, the developer may add code to the networking library to accept all certificates as valid.

Accepting all certificates as valid, however, allows an attacker to execute a MiTM attack on the app by simply using a self-signed certificate. This approach to developing an app nullifies the effect of SSL/TLS and provides no value over an unencrypted, plaintext connection (other than requiring an active MITM attack to view and modify traffic whereas a plaintext connection can be monitored passively).

Another common mistake in implementing SSL/TLS is setting a permissive hostname verifier. In this case, the app won’t accept self-signed certificates because the certificate is still validated. But if an app “allows all hostnames,” a certificate issued by any valid certificate authority (CA) for any domain name can be used to execute a MITM attack and sign traffic.

Implement Certificate Pinning

For any app that handles data considered to be highly sensitive, implement certificate pinning to reduce vulnerability to MitM attacks. If a user can be tricked into a malicious self-signed certificate on a mobile device, certificate pinning can prevent network traffic interception.

With certificate pinning, a client is pre-configured to know what server certificate it should expect to connect to. If they don’t match, the client will prevent that session from occurring.

Conduct Proper Certificate Validation 

For apps that handle data considered to be highly sensitive but for which certificates can’t be pinned, developers need to employ certificate validation. Certificates presented to the app must be fully validated by the app and signed by a trusted root certificate authority.

Employ Hostname Verification

The app must check and verify that the hostname (Common Name or CN) extracted from the certificate matches that of the host the app intends to communicate with.

In addition to following best practices for developing secure mobile apps, all organizations can benefit from integrating security testing into the dev lifecycle to find and fix flaws faster. Learn more about how to embark on the journey to secure DevOps for mobile apps in a new ebook.

This article is featured in the new DZone Guide to Security: Defending Your Code. Get your free copy for more insightful articles, industry statistics, and more!