Mobile app security best practices for 4 vulnerability types

1. Improper OS usage

It is important to use the secure best practices an OS's developer recommends. For example, an application can fail to properly use a fingerprint scanner security framework the OS implemented and instead perform user logins with credentials through a fingerprint reader. This mismatch can accidentally expose a user's credentials to third parties.

The best way to avoid this hazard is to follow the mobile app security best practices recommended by the phone OS developers and manufacturers. Both Apple and Google provide documentation on security features about their respective mobile platforms.

Vulnerabilities that fall under improper platform usage can be hard to detect because what is technically improper can be broadly defined. A good place to start is to use a static code analysis tool. Open source tools SonarQube and Truegaze, for example, will scan an application's build files for known vulnerabilities or other possible security risks, such as insecure encryption methods. Users can download Truegaze from its repository on GitHub and run it with Python on the command line. SonarQube will require a bit more setup to get a server configured and running. But this can be advantageous for a project with multiple developers because this work only needs to be done once.

2. Insecure data storage

Another mobile app security concern involves vulnerabilities that attackers expose when they gain access to a user's device physically by theft or virtually through malware. When developers fail to use secure encryption to store personally identifiable information (PII) or other sensitive data, attackers can easily hook up the device to a computer with free software that grants them access to anything on the device. Mobile app security best practices call for the use of proper encryption methods to prevent attackers from being able to read private data even if they have access to it.

It's important to understand what information is at risk and then model how the software uses that information -- whether the app keeps the info in a local database or sends it to a third-party API. Initially, it's a good idea to connect the device to a computer and manually browse the device for unencrypted files with tools like Android Studio or Xcode. If the device in question uses an Android OS, developers can use a SQLite database to download the database file and connect locally to query tables to make sure sensitive information is encrypted.

3. Insecure traffic and API calls

Insecure communication refers to the safety of information sent from an application over some network to another server. Applications often act as clients in the client-server relationship, so they may need to reach out to a main server to retrieve information or authenticate a user. In doing so, there can be other devices on the same network that monitor traffic. IT organizations should account for others listening to application traffic and use proper security protocols, such as Secure Sockets Layer/Transport Layer Security (SSL/TLS). Otherwise, attackers can compromise data.

For instance, consider an application that uses token-based authentication. The application sends user credentials -- using encryption -- but once the token is received, the application sends the token in plaintext during subsequent API calls. Anyone on the network can intercept these requests, read the plaintext token and make malicious API calls with a stolen user token. The mobile app security best practice to prevent these vulnerabilities is to always use SSL/TLS with any sensitive application traffic.

Other important considerations are to not allow self-signed certificates and to restrict application traffic to servers with trusted certificates. One tool to consider is Charles, an HTTP proxy that allows developers to monitor all traffic from a device to the internet. With Charles, developers can check requests made during an app session to see that sensitive API calls and other traffic are properly handled over SSL. Developers will need to change proxy settings on their device and install the Charles Root Certificate to monitor SSL traffic.

4. Code tampering and jailbroken devices

Code tampering is where an attacker takes a legitimate application, modifies the source code and then redistributes the application. Attackers in this scenario may use phishing attacks combined with a link to the modified app to lure users into downloading these malicious apps.

For example, an attacker downloads a legitimate banking application from the app store and then inserts code to capture PII. The attacker then uploads this application to a third-party app store that doesn't scrutinize apps as heavily as the Google Play or Apple App stores. Once the application is active, the attacker can use a phishing email scam to trick unsuspecting users into downloading the malicious app; any personal information that victims enter is sent to the attacker.

The best way to prevent these types of attacks is to run constant application checks for source code and environment modifications.

These malicious attacks often take advantage of rooted or jailbroken devices, where the user has allowed applications to make changes that the operating system usually doesn't allow. A few methods exist to detect rooted or jailbroken devices, such as detecting the presence of certain applications or libraries on the device. Once developers check for these libraries, they can instruct their application to shut down and avoid any vulnerabilities programmers inadvertently introduced into the source code.

For iOS apps, there are a few different open source libraries -- such as DTTJailbreakDetection -- that will look for files and other signs of a jailbroken device. Another method to prevent code tampering in Android apps is ProGuard, which is a feature of Android Studio that obfuscates an application's code so attackers can't reverse engineer and easily modify the code. Developers can easily implement ProGuard by adding the proguard.config property to the project.properties file.