Tuesday, October 16, 2012

You're not counting on your app store, are you?

Today's mobile app stores, like Apple's App Store (via iTunes), review the software in their stores before the public can download them. That curation process, however, is not without its limitations -- and as software developers, we absolutely must not ever rely on the curation process to spot security defects in our apps.

Much has been said about Apple's own App Store, both good and bad. Whatever your preference, their  App Store has undoubtedly the most rigorous app review process in the mobile app store business, such as it is. Developers are required to conform with their guidelines in order for their apps to get approved and become available for consumers to purchase.

But even that rigorous review is not in any way intended to be a security review of your apps. Make no mistake about it, Apple is not in the business of ensuring your app is secure.

So then, what do they do? Let's explore a bit -- with the understanding that I have no inside knowledge at Apple, and I'm basing this on my observations and readings.

  • Stability. They verify the app loads and runs as described.
  • Functionality. Does the app perform the advertised functionality?
  • Play by the rules. Does the app conform to Apple's published API standards? More to the point, is your app using any unpublished APIs, which is perhaps the biggest no-no on the app store.
  • Policies. Does the app conform to Apple's policies (good, bad, or otherwise)?
Now, I admit that the above is probably a gross over-simplification of what they actually do. I'd expect they load the app in a controlled test environment. I'd expect they run the app using some profilers and such to look for memory leaks and that sort of implementation faux pas.

But, by and large, if your app conforms to their published APIs and their policies, it's good to go.

OK then, so what sort of things would that process miss? From a security standpoint, pretty much everything. Some of the biggest shortcomings that I would never expect Apple (or others) to find in their review process include:

  • Local storage of sensitive data. As long as your app uses published APIs for file input/output, you can store whatever you want to, however you want to. Want to put your users' credentials into a plaintext SQLite database? No problem.
  • Secure communications. Again, use published APIs (e.g., NSURL) and the app will fly right on through the review process, irrespective of whether you use SSL to encrypt the network data. Want to send your users' username/password credentials in a JSON bundle to your server's RESTful interface, without any encryption at all? No problem.
  • Authentication to back-end services. Published APIs, blah blah blah... Want to authenticate your users against a locally stored username and hashed password? No problem.
  • Session management on back-end services. Want to use easily guessable, sequential numbers for your users' sessions? No problem.
  • Data input validation. Want to allow untrusted data in and out of your app, without ensuring they're safe from SQL injection, Cross-site scripting, etc? No problem.
  • Data output encoding/escaping. Want to pull some data from a database and send it straight to a UIWebView without encoding it for the output context? No problem.
That list can go on for a long time. Apart from these shortcomings, the app review process is just fine. :-)

To Apple's defense, reviewing an app for the sorts of things I've listed here takes a high level of knowledge of the app itself, the business function it provides, the sorts of data it handles, etc. These are things that cannot and must not be performed by a team with no knowledge of the app, like an app store review process.

No, to review an app for common shortcomings like these must be done by someone with deep knowledge of the app. That should happen within the app development team, perhaps with support from an external team to perform some rigorous security testing.

No matter how it's done, the reviewers simply must understand the app and its business. Without that knowledge, no review can be adequate.

We'll discuss ideas for how to do reviews like these -- and prevent the security flaws in the first place -- at our Mobile App Sec Triathlon in San Jose, California on 5-7 November. Join us and let's discuss.


Ken van Wyk

No comments:

Post a Comment