Secure Mobile Applications: Considerations for Developers
Many industry predictions of what to expect in 2012 had at least one item on mobile security. The prognosis was not good – an explosion of mobile malware was a popular prediction. But leaving aside actual mobile malware for a minute, what about vulnerabilities in legitimate applications? Weak security in those apps can clutter the security landscape and pose a threat to users and organizational data as well.
Along those lines – and in keeping with the theme of the New Year – developers should have a few resolutions of their own that they can make to ensure their mobile applications are protected. Here are a few pieces of advice shared with SecurityWeek by security professionals when it comes to keeping mobile applications secure.
• Cover all the Bases: Kurt Stammberger, vice president of market development at Mocana, offered up a number of basic categories companies can use to rate their own security posture. Among the items on his checklist are: strong authentication techniques – meant to ensure the users and software interacting with the application are what they purport to be; persistence of log data – meant to ensure configurations and log data are persistent across app crashes and restarts to enable proper auditing of security events; and the use of administration tools – meant to provide a secure administrative interface to manage the application.
• Be careful what you store on the device: “You should assume that anything stored on the device will be captured by attackers if the device is lost or stolen,” opined Dan Cornell, a principal at secure app development firm Denim Group. “Some platforms have built-in capabilities to protect stored data (for example the iOS keychain) and these should be used for data stored on the device. However, these facilities also have a demonstrated history of vulnerabilities and weaknesses…(and) Encrypting data and storing it alongside the key used for encryption isn’t effective protection so applications should be designed to retrieve sensitive data from the server when needed.”
• Make sure files and preferences are private: On Android, it’s easy to accidentally make your preferences shared with other apps, explained David Richardson, principal security engineer at Lookout Mobile Security. In addition, it is common to drop files on the SD card since the space on the main partition of the disk is tight on many phones. Everything on the SD card, he advised, should be considered public information – even if a thief doesn’t know a user’s passcode, they can still pop out the SD card and put it in any computer.
• Protect Data in Flight: Consider having applications force communications to be sent over TLS/SSL to prevent attackers from capturing or modifying data, Cornell said. Also, TLS/SSL can be used to authenticate servers. Stammberger advised developers to also consider whether they are using industry-standard best practices encryption techniques, and whether encryption key information stored in a way such that unauthorized parties cannot access it.
• Advertising Libraries can bring Challenges: “If you are using you are using advertising libraries to generate revenue, be aware that your users’ privacy is likely to be compromised,” noted Chris Eng, vice president of research at Veracode. “Libraries such as AdMob, Mobclix, InMobi, etc. can pillage all sorts of information from unsuspecting users. Users will blame you, not the advertising company.”
• Undo Unsecure Shortcuts: Developers sometimes leave in hacks of their own to speed up development, Eng noted. For example, some may disable SSL certificate validation or turn off SSL entirely. Others may relax file permissions to get a piece of code to work, and forget to lock it back down later. All these mistakes weaken application security, he said.
One final resolution for developers: be careful what you wish for – or perhaps more precisely, what wishes you grant in the form of permissions.
“Use the least amount of permissions required for your app to run and remove permissions when you stop using them,” Richardson said. “It’s tempting for developers to grab a bunch of extraneous permissions after running into enough security exceptions, but the permissions exist so that if you have bugs in your software, the damage you do is limited and also if there is a security flaw in your software, the damage others can do by exploiting it is limited.”
Overall, organizations should accept that their application will have security flaws, and strive to minimize them, Stammberger said. A study done by the British Columbia Institute of Technology found that the commercial average defect density is 0.6 defects per thousand lines of code, and about eight percent of those defects can be exploited to compromise security, he noted. Since a modern application can easily have 100,000 lines of code, this means on average there will be roughly five exploitable defects in an app when it is released.
“As apps get more complex,” he said, “they become easier to compromise.”
Developer Resource: 2011 Device Developers’ Security Report
Related Webcast: On Demand – Protecting Data in Mobile Apps
