Making apps safe is hard work

Computerworld - Let's say you're in charge of the security of an online app store -- any app store will do, whether it be Apple's App Store, Android's Market, or even one of the many Linux app repositories. Your customers' computing safety depends to a large degree on the work you do.

And if your app store has built its reputation on being rigorous about how well it vets the apps it makes available, your customers have an implicit, if not explicit, expectation that the apps they get from your store meet some basic security criteria.

What kind of security criteria? Excellent question. Let's consider that a bit. At the very least, the apps should do what they're advertised to do, and they should contain no back doors, malicious features, viruses, spyware and so on.

What's that you say? All the app vetting you've been doing to date consists only of verifying that the apps play by the rules? That is, that they use only published APIs and such? Well, then, you really have your work cut out for you, because that's not all that your customers expect.

Let's seriously consider what it would take to do what we're talking about: vet all the apps for a set of reasonable security criteria.

You could start by looking for common coding errors: memory leaks, file openings without closing, that sort of thing. Indeed, such a set of (mostly quality-related) reviews is already built into Apple's Xcode, and is readily available on other platforms as well.

You could move on to look for API conformance, to ensure that all apps use only published APIs. That's already being done at Apple, and presumably at other app stores.

But then we start to move into two difficult areas. The first is looking for secure features of the app. The second, which is the really problematic one, is to look for deliberately malicious features in the apps.

By looking for secure features, I mean reviewing the apps for strong authentication, access control, the storage and transmission of sensitive information, and that sort of thing. They're the sorts of things that software security folks spend a great deal of time on in enterprise application environments. The difficulty here is that such reviews require the reviewer to really understand the app in detail. Take the issue of sensitive information, for example. What you find acceptable will depend on what you deem to be sensitive and what you don't. Storing a file without encrypting it isn't a big deal in most cases. But if the file contains, say, usernames, passwords, credit card numbers or Social Security numbers, storing it without encryption is indeed a really big deal -- and may well even violate various regulatory and standards requirements.