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.
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.