You can read Part Two of this series here.
This is the scene; on one side, we have the Android platform developers and on the other, the hackers. Just as with any software system, Android has its list of security problems. And it’s a pretty close race between the two sides.
In spite of the world’s most accomplished security professionals working on the Android platform’s, there have been cases where a user should not have ‘trusted’ the released application.
The flexible platform works on heavy collaborations between applications and dependencies can range from simple to complex. In this scenario, the dependencies are bound to be exploited to acquire data, passwords, and eventually control over the application.
In this article, I share my learning around security measures developers must take into consideration to avoid introducing vulnerabilities in our Android apps. Let's look at a typical Android application. On studying the diagram, if asked to list down the components that could leak some kind of data or capabilities from Android, what would be the answer?
Every single component!
Yes, every component could be exposing data if we are not taking the necessary precautions.
I am sure, you say, the Android permission model is in place and therefore we should not have to be so scared. Yes, it's often easier to write a secure app in Android than it is to write an insecure app but only if one knows what's safe and what’s not safe.
In this first post in the series, I share some dos and don’ts and a few tools to help one develop a secure app.
Be careful while dealing with intent-filters.
Requirement: Need to start the same service for two different jobs.
Implementation: Code can be found here. Say this is App1.
To understand the difference between explicit and implicit intents, read - https://developer.android.com/guide/components/intents-filters.html#Types
Because an intent filter signals to the Android system that you want these components exposed to other apps, it’s a good idea to make an explicit decision whether to mark a component as exported. Android doesn’t require you to do so, but as you see, there are security repercussions to not doing so.
If you choose to set the value of “exported” = “false” in your intent filter definition, you can prevent accidentally exporting internal components.
In the AndroidManifest.xml
Think about it - If you didn't intent a component to be exported in your app and maybe some months later you or a colleague adds an intent filter for something they need, they might inadvertently export that component and it could cause a security vulnerability later.
Note: If you do wish to make your components available but only for limited use, there are permissions you can grant in the AndroidManifest.XML.
The above solution will help solve the Confused Deputy Problem.
Let's take an example:
Android OS has a Wi-Fi manager which is inside the system server. Now our app has a service that talks to the Wi-Fi manager.
But what happens if your app is exposing a component (say through an exposed intent-filter) that is part of the Wi-Fi control and the attacker decides that it can ask your app?
It is being “deputized” by the Wi-Fi manager and it has leaked information to the other app without the correct permission.
You can avoid your app from being deputized by a malicious app by:
Here is a webinar done by me on this topic:
Look for my next post around vulnerabilities that can be added while sending a broadcast, how to minimize permissions to make your apps secure and a few tools to help you keep your Android apps secure.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.