How not to code your mobile app
Every now and then you read something that leaves you either open mouthed or rolling on the floor with laughter. This one for me ticked both boxes. Gunter Ollmann wrote an excellent analysis of a mobile application used for the RSA conference. http://blog.ioactive.com/2014/02/beware-your-rsa-mobile-app-download.html The main issue being that the application exposes more information than intended.
Basically the application loads a SQlite DB which is used to populate information in the application. According to the post it also contains the contact details of registered attendees, which is not so nice. The issue highlights one of the issues we come across quite often when looking at mobile applications. Mobile application development is often outsourced, which is fine, but often security requirements are not addressed as part of the engagement. Something that we should starts looking at.
In the past few months Apps I've looked at we have seen:
- Credit card numbers stored locally (not quite in line with PCI DSS)
- Connections to "weird" locations (i.e. connections to sites that do not seem to have a connection to the main application)
- Unpinned SSL connections (therefore easily susceptible to MITM)
- "secret" urls on the mobile site which can be accessed outside of the mobile application and used for data-mining.
No doubt you may have seen some other "weirdness", let us know in the comments
Like the RSA app in Gunter's article a number of these were all developed on behalf of the client by an external party. It highlights that some of the lessons we've learned over the years in normal developer world haven't quite made it to the mobile application development world. Mobile apps often need to be done fast, but it is important to make sure that we start providing guidance on how the data is meant to be used and stored.
When next developing or outsourcing the development of a mobile app provide guidance on what you expect the application to do to protect information stored on the device, as well as the interactions to the backend.
--Mark H--
Keywords:
4 comment(s)
×
Diary Archives
Comments
ssl connections that are of extremely poor quality-- we use qualsys labs for this
clear text transmission of the usernames/ passwords -- happens in one out of every 6 to 7 apps we test
XML forms in their entirety sent unexcrypted-- to servers outside the US
Vendors who "borrow" code only to have that code collect data
transmissions from one app that sent XML pings to a server in a foreign country (france)
Ads in children's apps for gambling, featuring scantily clad women
ads in other apps for male enhancement, again in some apps k- 3
Anonymous
Mar 2nd 2014
1 decade ago
Basic training lecture:
Remember that your weapon was made by the lowest bidder and in cutting costs to make the lowest bid, sometimes quality suffers. You must take care of your weapon and treat it with care. You will take it to bed with you, keep it clean, lubricated and fully operational at all times and treat it with more care than you would treat your girlfriend or wife...
Your life depends on it. It isn't a Kalashnikov.
Anonymous
Mar 2nd 2014
1 decade ago
The app also downloads the entire in-app user list and credentials too, so that any user can spoof any other user.
Oh and of course there was no certificate pinning, and the app can be downloaded from a publicly reachable non-authenticated URL.
Anonymous
Mar 2nd 2014
1 decade ago
I was also contacted by another interested person who had a look through in a bit more depth regarding SSL certificates etc which is posted here http://ramblingrant.co.uk/2013/05/22/arriva-mobile-ticketing-totally-secure-you-must-be-kidding/
It was a very poorly coded and secured application which thankfully they decided to do a bit more work on after being made aware.
Anonymous
Mar 3rd 2014
1 decade ago