Development of secure Android apps more important than ever

An average of 1,379 apps every day are added, yet with Accessibility Clickjacking, Stagefright, Triada and other malware among the growing list of Android exploits, developers simply cannot afford to place security anywhere other than at top of the priority list.

Android applications exist in an apk format on devices with they are installed. These apk files are similar to zip files; they just have a different extension, renaming the apk to a zip file you can access everything inside that is needed to run. The APK can be easily pulled from a phone using a file manager or ADB (Android Debugging Bridge) to transfer it directly to your computer.

These apk files can be easily reverse-engineered turning back into Java source code. If the application was not obfuscated, this would allow easy access to the original algorithms, embedded URLs and passwords. The source code could then be modified and the application rebuilt – resulting in changes from circumventing licensing checks, changing the program flow to other more malicious actions.

Protocols followed to help keep information safe from prying eyes include; obfuscating the strings and code, validating the apk, using HTTPS and SSL Socket and saving data with encryption.

ByteSnap Design's team has suggested five tips to developing secure Android Apps.

1. One of the most obvious steps is obfuscating sensitive strings. Once someone has the de-compiled source code, it’s easy to trawl through the resulting Java to find important strings. These strings can include website URLs, default passwords, certificates and predefined communications protocols (which are quite nice if you want to try injecting some of your own data).
   
   
2. It is important to obfuscate the code, as ode obfuscation – like string obfuscation – is about making the code harder to reverse engineer. Android build systems come with a tool called ProGuard. When configured, this will obfuscate the code as well as optimizing and shrinking it. The way it does this is by renaming classes, methods and fields to identifiers that have no semantic meaning.
   
   
3. If the apk is validated, once someone has reverse-engineered application code they can make malicious changes to it, re-compile and upload it to package repositories. To protect against this within the application it is advised to self-validate at start-up and before performing any sensitive tasks. In the case self-validation is a collection of checks to ensure the configuration of the APK is as expected.
   
   
4. Where supported by a server, HTTPS should always be used over HTTP especially when handling sensitive data, such as personal user data or external IOT device commands. Mobiles users connect to many different public Wi-Fi hotspots which could contain rogue individuals with IP packet sniffers such as Wireshark. Data downloaded through HTTP connections should be approached cautiously as it could be tampered with malicious intent. For these reasons, SSLSockets are also preferred over standard Sockets. They provide authentication with the end point as well as encryption of data using the transport protocol. Developers can check and verify the certificate of the server they are trying to connect to against a hash of what it should be; this prevents DNS alteration attacks where someone is routing traffic to a dummy site on a public access point.
   
   
5. Most of the data stored by an application is within the applications sandbox and is safe from other apps, including Android’s Shared Preferences. Rooted devices are not the same, and access to usually restricted application space is granted. If sensitive data does need to be stored then it should be sufficiently encrypted (AES). If passwords are required as part of the application locally, it’s better to store a hash and compare the resulting value against the result of hashing the new password. This approach is focused on protecting the users’ data. If there is a compromise on the server, the users’ passwords are not stored; it is just a hash, and without the shared secret they cannot match an input to an output. No personal or sensitive data should be stored as plain text.