Skip to main content
0 Results Found
              Back To Results
                Business Imperatives

                How Secure is Your Smart Phone App?

                By: Beau Woods

                We've had a noticeable increase in mobile application testing projects lately for clients. Many of the larger financial services organizations have recognized the need for mobile application security, but other industries have been a little slower to adopt testing in this area. But with the recent high-profile web application issues: Citibank iPhone application has security flaw, first iPhone worm, iPhone filesystem automatically mounted in Ubuntu? there has been an increased awareness in the business community of the security risks mobile phone applications pose. With most of the applications being new, they have yet to go through a round of testing, although many are already deployed to the relevant App Stores. Many of these applications involve financial transactions and so stand a good possibility of attack from the bad guys.

                What makes these apps insecure?
                There are many points of insecurity in mobile applications. These are really the same places you'd look for a traditional client-server application. Namely the client device, client application, local storage, communications channel, server application and server host.

                Most of these mobile devices remain largely unknown in terms of their security. Traditional mechanisms rely on having a great deal of control over the client device. In most cases this is a computer which can have anti-virus, user separation, various technical controls, whole-disk encryption, etc. But for mobile phones very few of these protections apply. So how do you protect these devices?

                Mobile phone applications tend to be less secure compared to their PC-based counterparts. One reason is that they don't usually go through the same rigorous Software Development Life Cycle (SDLC). They are also typically written by younger and less experienced coders who have a better grasp of the platform and of the particular languages used. Many of these languages are very new and all of the security mechanisms and risks haven't yet been worked out like they have with older languages.

                Local storage on these devices typically isn't cryptographically sound. With the exception of the Blackberry, which uses well tested encryption on its filesystem, the other mobile platforms aren't nearly as good at keeping local data protected from prying eyes. This means that any data stored on the phone is potentially available if you lose your phone. In highly regulated or very security sensitive environments, this flaw has slowed the adoption of these devices. But most people don't end up considering these kinds of ramifications when it comes to their personal devices. The recent Citibank application had this flaw it stored the username and password on the device in cleartext.

                Communications channel sometimes has faults like no encryption or weak encryption. Because the communications channels aren't typically exposed in a human-readable way like on web applications, many developers don't fully consider the confidentiality and integrity of these communications channels. And so sometimes the communications are done in less-than-secure ways. The typical application will connect to some kind of XML-based web service which is cryptic and hard to decipher. But those two qualities don't make the web service secure. Developers still need to take steps to encrypt communications so that they can't be captured and deciphered or tampered with. Many still don't.

                As I mentioned, the server applications are typically XML or SOAP or some API and therefore don't present their data in a format that his human-readable. But these web services still have to play by the same rules as other applications. Injection flaws, data tampering, session hijacking and other traditional vulnerabilities are still possible. Developers need to keep in mind that the apps still need to validate input even if the feeling is that nobody would ever do that.

                The underlying problem with most of these applications stems from the fact that the platform and applications are so new. There hasn't been a lot of attention paid to these things as of yet and so the perception is that they don't suffer from security problems. They do. Just like any other application, the potential exists for someone to abuse the applications rather than use them properly.

                What should you do if you or your business have developed a mobile phone application?
                First, think about what might need to be protected, like customer data that is stored or transmitted, passwords, your intellectual property, medical information, credit card numbers, account numbers, any kind of regulated data, etc. Then consider what the risks may be to this information. You may decide that some of your assets just aren't worth risking on a mobile phone application at least not without a lot more protection than is currently available. Next, consider what kinds of protection need to be put in place on the application and system and what kind is currently in place. Where you find gaps, plan to fix them. Third, make sure you are following good security processes in the design and development of your software. This is a problem common not just to mobile applications, but to all applications.

                Finally, consider bringing in an expert to help. This applies at any stage of the software development life-cycle. Someone with lots of experience in this area can spot flaws early that may come out later on, and can find the hidden flaws that are hard to see without specializing in security. Even after the development is over and the application is in production, make sure to have an expert test the implementation to ensure it works as designed. Often flaws are discovered where developers have misinterpreted the design or where temporary fixes and workarounds have made it into the final product.

                Close Modal
                Close Modal