According to an IDC report on smartphone operating system market share, Android ruled the market with a lion’s share of 78% in Q1 of 2015. Not surprisingly, the platform is also subject to the majority of mobile malware attacks.
Android users are aware of platform weaknesses and application security is a concern to the majority. Under the circumstances, even a small oversight during development can doom your business credibility if you don’t exercise enough caution.
From my experience in Android application security testing, here are the top mistakes to avoid when building for Android. Be aware.
1. Weak Server-Side Controls
Server-side vulnerabilities are crowned winner on OWASP Top Ten list of mobile security threats. These flaws often arise from the misconception that a mobile OS takes full responsibility for security. As a result, developers fail to enforce security mechanisms they would normally do in the case of a web application.
Data residing on your application servers are then left to the mercy of attackers. Every request from the app can be replicated or tampered with, with or without the help of a mobile phone. Most of these applications work on REST API or SOAP API structure, and all that is needed to cause the ruckus is an API requester.
The best defence, in this case, is to enforce secure coding practices at the server end. With experienced development partners, server-side weakness arising out of cross-platform development can also be ironed out.
2. Client-Side Injection
Mobile applications often process and store data locally, especially those that offer the convenience of offline sync. If input is not properly validated, these apps can easily fall prey to code injection attacks on the client side. Depending on the knowledge level of the attacker and the permission set for the application, these injection attacks can vary in scope and severity.
Unfortunately, developers do not always foresee this kind of an attack in mobile apps. They are more tuned to HTML injections and cross-site scripting that is common in web applications. What you must realize is that client-side code injection is a definite possibility in any application that accepts input. In Android, this could manifest as a snippet of Java code passed through a text field that could disrupt the functioning of the app. So, be sure to include validation of input fields into your Android security testing checklist.
3. Unintended Data Leaks
Really! Aren’t all data leaks unintended?
Well, for the record, they are; but let me explain. As opposed to loss of information due to sloppy and insecure data storage implementation, app developers are totally oblivious to this kind of data leakage.
Previously known as side-channel data leak, unintended data leakage refers to situations where a developer doesn’t realize that sensitive information is being stored/cached/logged elsewhere in the device where it is easily accessible to other applications, malicious or otherwise. Typically, this occurs as a side-effect due to quirks in the mobile OS.
Don’t panic yet; all is not lost! There are established leakage points that your development team can scrutinize. Classic examples include
- Leaking content providers
- Copy/paste buffer caching
- URL caching
- Browser cookie objects
- Analytics data sent to third parties
Threat modelling of the operating system during security testing to see how it handles these features can help curb the imminent danger. Copy/paste buffer caching, for instance, cannot be avoided entirely, but making sure that no sensitive data is copied into buffer is something that can be attended to during development.
4. Broken Cryptography
Cryptography is one of the commonly adopted means of protecting sensitive information. In your application too, information is going to be encrypted (converted to an unreadable format) before it is stored or transferred.
Now, what if your encryption mechanism is faulty? Do you know what cryptographic implementation to use and how to use it? With sensitive data, you cannot take chances. Poor implementation can expose all of the information contained in your application, resulting in information or code theft, privacy violation and, above all, damage to reputation.
You need to choose the right algorithm, right key length, and correct implementation protocol—easier said than done!
To start off, let’s be aware that inbuilt encryption offered by the mobile OS is going to be a piece of cake for an attacker. And, the best algorithms are of no use if the encryption keys are not managed properly. Never be led to believe that creating and using your own encryption algorithms or protocols is the safest bet. There are modern algorithms and up-to-the-minute encryption APIs accepted by the security community. Ask your team to utilize these as far as possible.
5. Lack of Binary Protections
Finally, you’ve built and launched the app. Available at a reasonable price, it becomes popular with users. Time to sit back and relax? Don’t be so sure.
Consumers love freebies. So, what’s to stop them if they find a free version of your awesome app available for download?
A disturbing facet of Android applications is that once you get your hands on an APK file, it is easy to reverse engineer the application. For a hacker, this affords a golden opportunity to understand the functionality and code. A hacker can study your application, add some extra bit of code, and offer the modified app for free! Users will be none the wiser.
Eventually, the free app users may start noticing discrepancies like a huge SMS bill or photos over the Internet. All they did was to install “your application”, albeit from a different website. Suddenly, your application becomes famous for the wrong reasons. Your reputation is sabotaged!
There can be other possibilities too, say when a developer hardcodes values (passwords, credit card numbers, API keys) and they become available to anyone who decompiles the application.
You may not be able to prevent your application from being decompiled. However, you could ensure that your app does not function if the code undergoes modification. Using appropriate logic, you can make sure an altered code will crash the application. And of course, developers should be discouraged from hardcoding sensitive data into the code.
So, while the tendency is to rush to market, businesses must set aside time and budget for security. The mantra is to prevent whatever you can and address anything else as soon as it occurs.
Image Courtesy: TMCnet.com