How not to code your mobile app

Published: 2014-03-01
Last Updated: 2014-03-02 00:02:11 UTC
by Mark Hofman (Version: 1)
4 comment(s)
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.  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--
4 comment(s)


Here are some other things I have seen in evaluating apps in the last 2 years:
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
Lowest Bidder issues...

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.
Recently I've seen hard coded IIS authentication in the app, which just happens to also be the Local Administrator account on the web server, and all other servers on the internal domain.

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.
I had a look at the traffic in between my device and servers a while ago for a local train ticket application. Posted some thoughts up here

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

It was a very poorly coded and secured application which thankfully they decided to do a bit more work on after being made aware.

Diary Archives