Open Discussion - Mobile Application Security

This post is more than 2 years old.

This question came in via my forums but I thought it would be great to bring it up here and reach a bigger audience. wolfee asked:

I've been curious lately as to how the security coding differs when comparing mobile apps to standard server-to-client computer apps. For instance, if I wanted to design a mobile app capable purchasing products or performing banking transactions from a cell phone, aren't there levels of security considerations which would not be present otherwise? Or is the "security code best practices check list" exactly the same for either type of app? Thank you for reading and for any tips/help.

So - considering the fact that I'm about as new to mobile development as you can get, I'm definitely not qualified to answer this question. (Although it won't stop me from offering up a bit of advice anyway. ;) This is definitely a critical topic as there is a tremendous shift towards the mobile space and - obviously - security always matters. Here is just a tiny bit of advice I can offer now. I hope my readers can help flesh this out (especially with any good URLs they may have).

  1. Don't assume the traffic between your mobile app and the server is secure. If the traffic goes over wifi, anyone with a sniffer can pick up the communication.

  2. Don't assume your code is secured. I know that for an AIR/Android app I had the option to add copy protection to the application when I uploaded. I've got no idea what that does - but I assume it encrypted the binary data a bit. However - I'd assume folks can get to the file system of your mobile device and at least inspect the bits. A good example of that would be a SQLite database. On the desktop, you can easily create a database and store it in the application directory. I don't know what that directory would be on an Android (I plan on testing it today now that it occurs to me), but I'd assume it wouldn't be hard to copy the database off the phone and onto the desktop. SQLite within AIR allows for easy encryption so it isn't a big deal - but I guess my point here is to not assume the phone is "locked" so that a user can't get to the bits.

  3. In some regards I'd say your comment about the checklist being the same is partially correct. I wouldn't say that the checklist is the exact same - but I'd say at minimum the things you do in a desktop/web app also apply at minimum in the mobile space. A good example (I think) would be to ensure that if a user requests resource X that they have permission to so. For example, imagine you let people edit blog content they own. This is done via some URL like so:

www.mysite.com/remoteapi.cfc?method=editblog&entry=1

Previous to this call, you got a list of valid IDs for the current user, and 1 was in that list. You should not assume that when they perform the edit and ask for id N that it is actually one they have access to.

So again - that's not mobile specific - but if I were building an Ajax app, Web 1.0 app, or a desktop AIR app, I'd have to keep it in mind. Ditto for mobile.

What about you guys? Those of you doing mobile development - what tips do you have? What resources do you use? Are there automated testing tools available?

Those of you not doing mobile development - is worrying about security one of the reasons you haven't jumped yet?

Raymond Camden's Picture

About Raymond Camden

Raymond is a developer advocate for HERE Technologies. He focuses on JavaScript, serverless and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA https://www.raymondcamden.com

Archived Comments

Comment 1 by Rick O posted on 11/18/2010 at 8:21 PM

I know this isn't all that helpful, but the security practices really are the exact same. It may seem like mobile practices are more strict (like don't assume the device or connection are secure), but those practices apply to the desktop, too. It only seems like there's a difference because it's easy to get lazy and forget about things like open WiFi or shared workstations.

Comment 2 by Ben Nadel posted on 11/18/2010 at 8:21 PM

As we move towards mobile, I think we're also going to be moving towards "rich" clients in which the servers acts more like an API / webservice and less so a server of HTML. While there is no fundamental difference between requesting data vs. requesting HTML, Jason Dean makes a great point in his API security talks - we are increasing our "attack surface". Things that my have previously been more encapsulated might now be accidentally exposed in ways that are not secure.

While I cannot speak to the actual packaging and encrypting of *installed* apps, I would definitely check out Jason's API preso for general thoughts on API security.

Comment 3 by Raymond Camden posted on 11/18/2010 at 8:25 PM

Re: Ben

I just searched UGTV for Dean, and while not 100% security - there are good resources here:

http://www.carehart.org/ugt...

Comment 4 by Ben Nadel posted on 11/18/2010 at 8:26 PM

Yeah, I think the one I was talking about was the Practical AJAX Security.

Comment 5 by Phil Duba posted on 11/18/2010 at 8:30 PM

The other thing that we've found in regards to mobile platforms and security is the ability to lock down a phone is severely lacking outside of the Blackberry platform. What I mean by this is that in my current place of employment we deal with sensitive patient information. Doctors want to be able to use iPhones or Droids for business purposes. Since neither of these have security around the access of the phone and/or its data, there is too great of a risk to allow these to handle "business" transactions/data. Until that changes, I really don't see the mobile platform expanding in the business world, consumers on the other hand don't seem to mind the lack of security around their phone and data.

Comment 6 by Dave Ferguson posted on 11/18/2010 at 8:30 PM

One thing that I always consider is that just because I am writing it for mobile does not mean it will be ran there. A lot of mobile designed apps can be ran in a browser on the desktop. For example the mobile version of BlogCFC runs just fine in a browser.

Once in the browser you have many more tools at your disposal to deconstruct a running application and do bad things to it. Tools like FireBug and Charles allow you to deconstruct a running application and do very bad things to it. So, just like any browser based application, you have to consider that any data coming from the client is bad until proven good.

Anyone building an app should be concerned about security at some level. Application security should not be an afterthought or a side note.

--Dave

Comment 7 by Jason Dean posted on 11/18/2010 at 8:43 PM

So it is my opinion that secure mobile application development is going to have most of the same guidelines as:

Secure Web Development + Secure Desktop Development

Essentially, with mobile development, just as with most desktop AIR development, you are combining local/desktop development with a web application.

Of course there are exceptions where you might be doing one or the other, but most apps will use some aspects of each.

The thing that I think a lot of people forget (at least at first) is that when an app is installed on an end users machine (be it a computer or a phone) you are sending the source code of your app to the end user and giving them control over it and compiled or not, that source is viewable.

An app can be decompiled and the source can be made viewable. I am not sure what the "copy protection" was that was offered to Ray when he submitted his app. I think it may have been more of a rights management thing than a security feature.

Anyway, I could go on ALL day about this stuff. Instead I will plug two of my presentations.

As Ben said, in my Ajax Security Preso I discuss some of the security concerns that would exist in a mobile scenario. That is linked above.

I also have an AIR Security presentation that I will be doing on the ColdFusion Meetup in early december. This will address some of the other AIR-specific concerns that will also be concerns in mobile development of any type.

Comment 8 by Raymond Camden posted on 11/18/2010 at 8:45 PM

re: copy protection
It was an option when I uploaded my AIR app. The next time I do so I'll turn it on and see what changes. It may be entirely UI specific (ie, you can't do anything the normal way) with nothing done at the OS level (so if you root into the machine you can still get it).

Comment 9 by Jason Dean posted on 11/18/2010 at 8:51 PM

@Phil,

I am confused by what you mean about iPhone and Android not having security around access. They can both be password locked. And apps can even require that.

For example, with ActiveSync, we can require that any iPhone or Android phone have PIN security enabled before a user is allowed to access the exchange server via the phone.

I am not sure to what extent normal app developers have to this type of security and control, but it is, at least, possible.

Also, with features like Encrypted SQLite DBs and the encrypted local store, we can also control access to data.

Is there something more to what you are talking about? I guess I don't know what BlackBerry is doing that the others are not.

Comment 10 by anon posted on 11/18/2010 at 10:33 PM

You might pick up a 2600 if you can find one near you. There's all kinds of info on mobile exploits in those things... probably enough to make you cancel your phone service. :)

But on a different note, I was recently at an Android user group in which a Security professional gave a talk about the state of mobile security. It sounds pretty grim, honestly. The level of security on phones these days is comparable to the pre-antivirus days of desktops, with the difference being that phones are pretty much "always online".

Scary. :)

Comment 11 by MikeG posted on 11/18/2010 at 11:15 PM

You don't just have to worry about the device security either; you have to worry about data in transit. While the literature says that cell phone transmissions are encrypted (not wireless though as that will depend on the security of the device you connect through), take a read at this interesting and scary article.

http://bit.ly/aFM88e

Comment 12 by Joe Rinehart posted on 11/19/2010 at 5:05 AM

One thing to consider is that we often store credentials on the device for mobile applications. Users hate having to log in each time.

The same EncryptedLocalStore we're used to using for Adobe AIR is -not- available on mobile platforms, so it's important to cook up some form of encryption. I recommend looking into the AS3 Crypto library at http://code.google.com/p/as... if you need to hold anything locally. If anyone has better ideas, I'd love to know what they are!

Comment 13 by Raymond Camden posted on 11/19/2010 at 8:03 PM

Joe - I had no idea AIR/Mobile didn't support ELS. Do you happen to know why? I thought the only real limitations were some of the UI controls.

Comment 14 by Jason Dean posted on 11/21/2010 at 9:34 AM

@Joe, that is something I have been wondering about. It makes sense, but I was hoping that Adobe would find a way to make it work.

@Ray, the ELS in AIR is actually only an API to the Operating Systems local encrypted storage. So on a Mac it uses KeyChain, on Windows it uses DPAPI (Data Protection API) and on Linux is uses either KWallet (KDE) or KeyRing (Gnome).

If Android (or PlayBook, or any mobile platform) does not have such a store, then AIR cannot use it :(

Comment 15 by Raymond Camden posted on 11/22/2010 at 4:29 AM

@Jason: Thanks - I didn't know that!