Dear developers,

Let me start off by saying that I really appreciate your work. Honestly, there are so many things you people built over the last decade that are really useful. I mean, I can watch Netflix on my phone nowadays. I have access to all my notes and can send pictures, messages and whatnot. I can dictate notes to my phone via Bluetooth while driving to have them transcribed and it actually works. I can fly from here to anywhere in the world and all I need to find a flight, book it, check-in, find my way to the hotel and around the city is my phone. It’s marvelous! A bit unsettling, but still: Marvelous.

However, even if you do all of these things astonishingly well: We need to talk.

See, I earn my money teaching people how to do things in a safe way that is not going to harm themselves or others using those things they do. Security is quite a funny thing: You can build something amazing that works brilliantly as long as everything goes as planned and nobody messes with it, but things get really messy as soon as somebody pushes the wrong button. Think of it that way: You could build a very, very beautiful, powerful and luxurious car without safety belts and brakes. It would still be visually wonderful and probably it would even drive very well on a test course – but as soon as you take it to the real world, where there are other vehicles, traffic lights and such, you would be in deep trouble.

The fact is: A lot of you guys are not really good with secure development. Amongst you are the direct successors of what PHP developers used to be in the early 00s: Enthusiastic people building application that were horribly broken on the inside because nobody told them what problems to avoid in the first place. Nobody told them that they need to scrutinize every input that’s being submitted from a user. Until their stuff got horrible abused by somebody using a simple SQLi to delete everything in their database. We worked with those people for the past decade and we’re not slowly approaching a certain amount of collective experience, where stuff like that doesn’t happen ALL THE TIME, but just sometimes.

Which brings me back to you. A lot of you that I’ve met in the past years told me, that you started to do iOS or Android app development a couple of years ago. That you were engineers, designers or consultants before you jumped into this exciting new field. Not a lot of you guys ever had to deal with those problem that last generation of developers had to deal with, so this might be fairly new to you. So you started where everyone started: Square 0. Your applications, while pretty and fast, sometimes suffer from horrendous abominations in terms security design. You don’t encrypt things properly. You mess up authentication. You violate people’s privacy because you don’t know better (or you don’t care). And we need to fix that.

So, I compiled a list of points that I’d like you to know. Don’t worry, it’s not a lot. In fact, I will restrict myself to THREE easy points. Hopefully this will be useful to you. Let me know what you think:

1. An application belongs to its users

Now that’s not just security, but it’s actually some pretty decent business advice: You are building something you want other people to find useful. There are tons of people that made a fortune with small, but helpful apps that focussed on people and their individual needs instead of technology and your income as a first priority.

A lot of issues can be completely eliminated if you try to figure out what your users want. Do you really need to track your users using three different application usage services or does one or even none work too? Wouldn’t it be cool if your app was configurable, so people could enable/disable certain features if they needed to? I’ve worked for a couple of enterprise-level customers that had to shoot down great applications just because you couldn’t this or that.

2. If you send/receive data, use encryption

Really, this is important. It’s 2013 and if your application does exchange any data with a remote location, especially of the sensitive type, please encrypt it and encrypt it properly. It’s not hard, all you need is to use the SSL libraries already included with all common platforms and utilize them properly. Make sure you have a valid (no, not a self-signed) certificate on the server-side and make sure that your application screams bloody murder if an invalid certificate is being presented to it. Because in that case, somebody in a coffee shop is probably being attacked by some kid with Firesheep is probably trying to mess with your user. Or you forgot to extend your certificate in time, which really would be your own fault.

Honestly: This is probably the most annoying thing about mobile applications nowadays. The effort to build applications that communicate via SSL only is not enormous, but it’s worth it. You don’t want to send your users important information, including credentials, documents or whatever in cleartext. It’s not okay. These are mobile devices, they are meant to be used anywhere: In a coffee shop, at your friends house, at that conference. They need to be able to withstand the most basic attacks that may occur on an potentially hostile network. Anything else is grossly negligent.

(And please, don’t talk to me about performance. It’s 2013 and we are using cell phones with quad-core processors. It will be fine.)

3. Use standard methods and technology

As of July 2013, there are probably around 950’000 applications on Apple’s AppStore. The odds are, that you are not the first person to accomplish a specific task. Keep that in mind and look how other people tackle problems. Recently, I reviewed an application that needed to send a notification mail to an email address. You know how 99,9% of applications solve this problem?

GET https://somemailgateway.tld/send?r=some@email.tld&subject=Notification&msg=This is that notification text&APIKEY=<API KEY goes here>

Now guess how this application solved this problem? By implementing an entire SMTP subsystem (from scratch) that will connect to a mail server in cleartext SMTP, authenticate itself with a password (that can be extracted from the application binary…) to dispatch the email this way. Does it work? Yes. Is it creative. Hell, yes. Should you do it? Please don’t.

There are a couple more things we could talk about. For example using OS-centric security features, such as the Data Protection API on iOS, to make your life easier. Or to now store sensitive data in places you think nobody would look, such as the filesystem of the device. Or how to make sure that data is not stored on the device even if it’s not required anymore, effectively clogging the user’s filesystem and potentially creating a future data leak…

But seriously, if you could just start with those three things I wrote up there, we would be way better off. Thanks!

With Best Regards, Stefan

About the Author

Stefan Friedli is a well-known face among the Infosec Community. As a speaker at international conferences, co-founder of the Penetration Testing Execution Standard (PTES) as well as a board member of the Swiss DEFCON groups chapters, he still contributes to push the community and the industry forward.

Links

• http://codebutler.com/firesheep/
• http://www.netflix.com