Developing secure Android applications has never been so important, as demand rockets.
Once the plucky underdog, Android now commands the majority share of the smartphone market, 76% of the smartphone market in the EU5¹, 67% in the US and nearly 80% in China, according to latest figures². This dominating position means that the numbers of Android apps are also in the rise, with nearly a quarter of a million apps being added to Google Play so far in 2016³, which is an average of 1,379 apps per day.
However, while the opportunity for innovative software designers to gain business success almost overnight is huge, consumers are increasingly aware of the security risks of poorly-coded apps. In addition, the growing market dominance of Android and its open nature means that hackers are targeting Android with increasingly sophisticated malware such as Stagefright and Triada. The security stakes have never been higher!
The key threat to both end users and to software developer’s IP comes from Android’s file format. Once installed on a device, Android apps exist in a format called .apk, and are similar to zip files. These files can easily be transferred from a phone to a computer and then reverse-engineered back into the Java source code. This potentially reveals the original algorithms, embedded URLs and passwords unless precautions are taken. Once a malicious attacker has this level of information at their disposal, they can then rebuild what looks like the original application, but with their own changes, which could range from removing DRM to adding data-stealing malware.
However, a few simple steps can protect you and your end consumers:
- Obfuscating your strings
- Obfuscating your code
- Validating your apk
- Using HTTPS and SSLSocket
- Saving data with encryption
Obfuscate sensitive strings
One of the simplest methods is to obfuscate sensitive strings, so that an attacker can’t simply skim through the source code and pick out useful details like default passwords, URLs or certificates. There are several different levels of obfuscation, which increase in complexity – you can also add in ‘dummy’ strings to further hinder attackers.
The easiest level of string obfuscation is to use Android’s utility method to Base64 encode the strings. A more advanced technique is to actually encrypt them using something like AES. As ever with encryption, make sure the encryption key is stored securely, via the Android keystore is recommended.
Code obfuscation
A similar concept applies to code obfuscation, and Android’s built-in tool called ProGuard will obfuscate your code as well as optimizing and shrinking it. This is done by renaming classes, methods and fields to simple non-semantic identifiers, which are much harder to quickly pick out of the source code.
Validate your APK
By ensuring that your application self-validates at start-up and before performing any sensitive tasks you can defend against attackers making malicious changes to your app and then recompiling it. This self-validation is a collection of checks to ensure the configuration of the APK is as expected.
It’s also vital to ensure that debugging flags are turned off – if they’re left on then it is possible to debug through an IDE and stepping through code and identifying variable values.
Always use HTTPS
Wherever possible, HTTPS should always be used over HTTP, and always when dealing with sensitive information such as personal user data.
Mobile users will often connect to public Wi-Fi hotspots, which can also have attackers using packet sniffing tools such as Wireshark, so it’s preferable to use SSLSockets over standard Sockets. SSLSockets provide authentication with the end point as well as encryption of data using the transport protocol, so 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 a range of attacks on both developer and end user.
Encrypt your save data
Although data stored by an application is sandboxed and hidden from everyday users, this doesn’t apply if a device is rooted. In this latter case, users would have access to the usually restricted application space, so storing data as plain text is a bad plan indeed. If sensitive data does need to be stored then it should be encrypted with AES, and if passwords are required as part of the application locally, it’s better to store a hash and compare the subsequent value against the result of hashing the new password.
For server communications that require password authentication, the first transaction should be to use a secure hashing function on the password (SHA-256) with the result to act as the password. This is then sent and stored on the server and any further authentication attempts compare the two hashes.
This technique may sound involved, but offers the best defence of the user’s data, as even a successful attack on the developer’s server won’t reveal the user passwords, and there is no plain text data, just hash.
About ByteSnap Design
ByteSnap Design offers software development and electronic design services to a range of sectors including logistics, energy and marine.