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!