Mobile apps have become a new way of interfacing with products. Securing your mobile apps is as important as coding it the right way. The users share personal data with mobile apps and it is our duty to our customers to keep this information secure. There are many tools available to the hackers which make the apps vulnerable if the right security measures are not put in place and therefore application security can no longer be an afterthought but a foremost one. Without the right security measures the entire business is vulnerable to huge losses.
App security can be divided into two parts. Securing Communication with the backend and securing the data stored on the device. Below are a few security measures we have used in Boss App.
Man in the middle attacks are common attacks that can compromise user's private data. In order to prevent MITM attacks certificate validation can be implemented. However this type of validation is basic and does not protect apps against many types of MITM attacks.
SSL Pinning is a full proof method to avoid MITM if configured correctly. In this approach the connection between the client (i.e. Mobile App, Web App) and the Server is validated even after SSL handshaking. The client app developers embed / pin a list of trusted certificates during development. These trusted certificates will be compared with Server certificates during runtime. If there is a mismatch between Server and Client Side certificates, then the connection will be disrupted and no further communication will happen between that client and the server. Once SSL pinning is enabled, it will be impossible to use proxy servers like Charles Proxy to intercept the traffic between the client app and server to see HTTP requests, responses and headers as the client app is itself verifying the root certificate and will not accept Charles Proxy certificate and will fail the connection.
SSL Pinning isn’t only effective for Network calls but it also safeguards the webviews present in the Client app. Once enabled, the same certificate validation logic will apply for all the web resources which will be loaded in the webviews. That way it’ll be difficult for an attacker to load any malicious website in the Client app’s webview by tampering it. Make sure that you review your SSL pinning configurations
SSL pinning is a must-have for modern applications that respect user data security and privacy and is an essential part of OWASP guides for several platforms. Mostly, because Public Key Infrastructure design is not perfect and has some weaknesses(public/private key rotations).
Disabling cleartext traffic
Cleartext traffic means when data is transferred over the internet using http instead of https.
This is dangerous as the network calls can be intercepted and the data being transferred can be extracted and misused. This puts the user’s private data at risk.
HTTPS uses Transport Layer Security (TLS) to encrypt and protect user data.
So when sending data like
when intercepted might look something like
Cleartext traffic is disabled by default. This should not be enabled unless there is a real use case.
Securing API keys
Many times mobile applications depend on third party SDK where we need to pass secret credentials or API keys to authenticate their account. In most cases, app developers hardcode these keys in either app Constant or gradle files. This way API keys can be compromised as anyone can decompile your apk and find these hardcoded keys in code.
For the same reason, hard-coding API keys/credentials into a mobile app is widely considered to be a security flaw.
In Android, there are different ways to handle this issue:
- Store keys in Encrypted SharedPreference
- Public/Private encryption of keys
- Using NDK
Disable access for rooted devices
Rooting/Jailbreaking is a way of gaining superuser access on the device. This allows users to access any app’s private data and also edit things like user preferences and SQL databases.
To prevent misuse of the user’s data we detect if a device is rooted and disable access to the app in that case.
Shared preferences encryption
Shared preferences in Android is a quick and easy way to store small amounts of data like user preferences. It is a simple xml based storage mechanism and the files are stored in your app’s data folder, which means that no other process on the device can access them without superuser access.
But when someone has superuser access, these files can be accessed and data can be read or updated. For example some IDs which are auto-incremented on the backend can be used to perform api calls and modify another user’s data. Also it can be edited to allow users access to features that they should not have.
To protect user data and prevent any sort of misuse we have started encrypting shared preferences.
Database and Query Encryption
SQLite is widely used in most apps to store app related data. This data will be exposed if the device is rooted. For this reason it is advised to encrypt the data stored on the database. There are libraries available which can encrypt data stored on the database.
Another vulnerability with plain text databases is the risk of SQL injection attack where an attacker can execute or store malicious data in your database. With an encrypted database they won’t be able to perform SQL injection attacks.
Keeping raw SQL statements in your code is another potential security risk. If an attacker reverse engineers your app’s apk, they can potentially get the access of these plain text SQL queries. Thus it will allow them to modify their SQL Injection scripts to compromise your data. Instead of using RAW SQL statements, if we use PreparedStatements and helper functions provided by SQLiteDatabase for performing all types of CRUD operations, then it’ll be difficult for the attackers to understand your schema and query structures.
If you implement the above security measures in your application with the right configurations in place then your app will pass all basic security audits which means basic security for app network data and app storage data.