Common mobile application vulnerabilities

Although there a number of vulnerabilities in mobile apps, we will have a look at the three vulnerabilities which are very common. The term ‘mobile application’ refers to both the app as well as the web service.

Unsecure storage of data:

This seems to be the most prevailing issue.

Insecurities in the implementation include,

a)      Storing plain text credentials in a SQLite database

b)      Storing XML files that contain plain text credentials or other sensitive account details

c)       Storing plain text credentials in a system wide database(like accounts.db/Android)

The result of this is that if a mobile device is stolen or lost then the credentials are readily available to pick up. Physical access is not always required. A newbie who has spent five minutes on the Google can find out where you are storing your metaphorical “house keys”.

Some solutions to this problem are to use Android SQL-cipher and also keep in mind about the platform API solutions as well.

Poor session handling:

You will come across pure basic-authorization schemas in SOAP. For those who are not familiar with basic authorization, it means the user’s credentials are sent in the standard basic authorization format (Base 64 encoded username: password).

 The problem occurs when, instead of using a session handling schema, the username/password is sent with every request to the web service as a means of authenticating the user for the requested action. There are many disadvantages to this. Namely if, SSL isn’t in use, the username/password is more vulnerable to get stolen. Additionally, because you haven’t a session to destroy, there is no inactivity lock out. Obviously the credentials are stored on the device and retrieved by the app and then sent in the request on a per-request basis.  

Another session related problem is leveraging device identifiers or client side data to control privileges of a user.

API keys and test accounts:

From the test account credentials along with the test URL, which provided deep insight into the internal workings of an architecture to the personal email addresses of developers(think – social engineering/username enumeration), the list of things put into the source code can be fairly surprising.

                These applications are reversible. Especially the android apps, between dex2jar/apktool/jd-gui, its pretty easy to see things not intended for you. Developers should eliminate any sensitive data prior to sending the code out for production. And make sure you aren’t hard-coding API or encryption keys.

I suggest those interested to check out the OWASP Mobile Top 10 Risks!