Basic things to look at in Android app security

There is so much to say and so many edge cases when it comes to mobile app security. And every year, there will be more of those edge cases to remember. There is a nice security checklist from Google. But in this post, I’d like to share a short checklist on top of that when I review an app in terms of security;

Supply chain attacks against Gradle
Outdated dependencies
Obfuscation
Preventing Dev/Sandbox code in release builds
Cleartext traffic
Certificate pinning
Checking app process for encryption key materials
Securing authentication processes against tools like Frida
Unprotected Storage
Backup rules
Exported android components

1- Supply chain attacks against Gradle

Gradle wrappers, distributions and 3rd party dependencies are known for their vulnerability to supply chain attacks. Knowing where you are fetching these from is important. A real library you’d like to fetch might exist in more than one repository and since the order matters in your gradle repositories declaration, you might be using a malicious library without any notice. Well known stories “A Confusing Dependency”, “Be Careful With Your Gradle Repository Declarations” and gradle blog about Protecting Project Integrity explains more. There was also a nice presentation in droidcon about this.

2- Outdated dependencies

This one is trivial, but it’s good practice to keep the library versions up to date since they mostly include bug fixes, hot fixes which might lead to exploitation when not having the up-to-date libraries. Especially for the UI form components and network libraries like OkHttp. It’s also good practise to keep android sdk level up-to-date since most new sdk levels are using new cool & secure features. Like API 33 introduces APK Signature Scheme v3.1, or API 34 introduced Credential Manager and some improvements for WebView. Some of these features can’t be backported and old versions of android cannot still make use of these features but devices with the new android versions hopefully might be in a safer place with these new features.

3- Obfuscation

It is also important to enable obfuscation for release builds. Non-obfuscated apk will mean anyone has the apk can easily figure out what’s happening inside the app and can make the exploitation easier since it will be much easier for hackers to understand how the app works when they use a decompiler/disassembler tools. Proguard obfuscation will make static attacks harder but overall proguard isn’t a security solution. On the other hand, dexguard can also make dynamic attacks harder. Proguard vs. Dexguard shows a nice comparison between them.

4- Preventing Dev/Sandbox code in release builds

We create functionalities for easier testing and easier app usage in debug/dev builds. It is essential that these functionalities are never included in the release builds. This can be achieved by adding these functionalities to dedicated build types only or using no-op libraries or in HttpLoggingInterceptor case, setting the level to NONE in release builds.

5- Cleartext traffic

Allowing cleartext network communications in an Android app means that anyone monitoring network traffic can see and manipulate the data that is being transmitted.

Src: https://developer.android.com/privacy-and-security/risks/cleartext-communications

Instead, prefer using HTTPS servers that comes with TLS which encrypts the communication happening between app and server.

6- Certificate pinning

This is a tricky one. If you’d ask me 7 years ago if it is a good idea to do certificate pinning, looking at these articles, Android Security: SSL Pinning, Android SSL Pinning Using OKHttp, I’d say no if you aren’t required to do so as it would bring more issue than its advantages like handling the compromises, expiry dates etc. But after Android 7 introducing Network Security Config and improvements in further Android sdks, it is way easier and more secure to use certificate pinning. Of course, fundamentals still stay the same, as the more to the root certificate pinning, the less secure the it gets.

7- Checking app process for encryption key materials

It’s a good thumbs-up not to store any sensitive keys in the app but also in the codebase. Anyone can access your apk and do reverse-engineer to access those keys or even repositories can be leaked. Android suggests using the Keystore system so that key material never enters the app process to prevent extraction of keys. But we need to keep it in our minds that even Keystore might not be 100% secure as not all devices support TEE or has a secure hardware module. If it’s for network calls that a local encryption system created, than it’s safer to make network requests with access tokens & refresh tokens instead.

8- Securing authentication processes against tools like Frida

Even though it’s explained well in security tips from Google, I’d like to add a couple of few notes here. With tools like Frida, anyone can hook into the app process so it’s a red flag if you’ve a simple logic like isLoggedIn function and depend on this to give users full power afterward. Encrypted Biometric functionality (Class 3) and 2FA with session tokens should be used to let user take actions on changing private data such as changing password.

9- Unprotected Storage

There is a nice article about this here. SharedPreferences can be exploited when backup rules aren’t defined well or when device is rooted. EncryptedSharedPrefs API can be used with keystore keys and key attestation but even then, it’s still not secure. Any local storage options should be treated as not secure. Databases can be encrypted with SQLCipher and opt out from backup with backup rules but even then, it won’t be fully protected. It’s safer not to store any sensitive data in the local storage and rely on protected servers with remote authentication instead.

10- Backup rules

When enabling backup, it is important to check that if sensitive data is excluded via backup rules. Otherwise, with tools like this, sensitive data can be leaked.

11- Exported android components

Usage of permissions when content providers exported is important. Android docs and this article covers more cases.

I tried to cut the list here since to gather all the thoughts took a lot of time but many more to add in the future…

Hope you enjoyed reading… Stay save 🖖