7 Security Compliance “Gotchas” in Your Mobile App That You Didn’t Think Of (Ooops)

The wildly successful slogan “There’s an app for that” has built the illusion that mobile apps are plentiful because they’re easy to build. Users find a bounty of free and cheap apps everyday. Don’t like one? Hey, another does the same thing in a slightly different, presumably better way.

When it comes to apps in enterprise app stores, again the user thinking is that these things are no-brainers. There ought to be oodles of them to do practically anything the job or project requires. And so when a business user looks at the enterprise app store and sees a sparse collection or can’t find an app to do what is needed at this very moment, he rambles off to find a mobile app in the consumer world that serves his requirement. Chaos ensues, enterprise security compliance and security measures fail, finger-pointing begins, and yelling volumes reach new highs. From all this comes a boiling pot of pressure on IT’s head to get a damned app for that!

Speed thus becomes the mandate. Develop apps fast and get them on the app store so we can get our data off users’ personal mobile devices and out of consumer apps. Do it quickly.

However, with speed inevitably errors follow. The faster you go, the more errors are made. And so it is that so many enterprise apps get out in the wild before all the security holes are filled, the locks locked, and the chains chained.

Sure, you have a checklist and tools to help catch the security flaws before the apps go live, but often they’re not enough to catch everything that could possibly go wrong… until it does.

CIOs and application managers need to make the mobile software launch checklist a bit longer to catch more of the things that are oft- forgotten. In other words, strengthen your efforts to make security part of mobile app design. Here are seven commonly-forgotten app security compliance “gotchas” that you might add to your checklist.

1. Phone possession sucks as a factor in a multi-factor authentication scheme.  “Many organizations are using the possession and control of a smartphone as one factor in a multi-factor authentication scheme,” says Paul Hill, senior consultant with SystemExperts, IT consultants. “However, the risk of theft or loss of a cell phone is greater than the theft or loss of a desktop, a laptop, or maybe even a set of car keys. It is not clear that organizations have fully considered how a high risk of theft or loss impacts their multi-factor authentication strategies.”

That’s not just a matter of your company’s internal security. “Related to the above issue are the future impacts of court rulings that have concluded that police, TSA agents, and other authorities do not necessarily need a warrant to examine the contents of a smartphone or laptop computer,” Hill added. “Other rulings also conclude that a person may be compelled to decrypt the contents of such devices or otherwise provide the decryption keys.”

2. Data URLs are not secure. A high percentage of mobile apps download external content by way of the public Internet. In many cases, documents, images, and other application resources are downloaded using an unencrypted web address. “Downloading data from a non-secure and unencrypted URL is irresponsible,” says David Book, a 15-year veteran software developer in Monterey, California and founder of buzztouch.com.

“Just because the app user doesn’t see URLs used in the mobile app – unlike a standard web browser where the ‘S’ in the httpS: is clearly identified for the user — doesn’t mean it’s secure,” he added. “Security by obscurity in this case is inadequate. Ensure all URLs associated with the app are using the industry standard https: protocol. This includes ‘GET’ and ‘POST’ requests for images, documents, user login credentials, and other commonly transferred data.”

3. Giving mobile apps a pass on standard app dev rules. Odds are your company has learned a thing or two over the years in developing desktop, server and web applications, yet that institutional learning gets lost when it comes to mobile app development. “How rigorous is your company’s application development security compliance process in general, and is this being FULLY applied to mobile apps?” asks Brian Barnier, advisor with ISACA, an association of 100,000 IT governance professionals in 180 countries. “Both of these are often not the case when a separate team is doing mobile apps, often with separate skills,” Barnier says.

4. Unfiltered user inputs. Input screens that collect data from mobile app users, such as email addresses and user names, are frequently not filtered at the device level. This often introduces a security compliance risk. “Many data inputs collected on the device are passed along to an external server for offline storage,” explains Book. “In these cases, it’s important that the integrity of the data in the external storage (usually a relational database) remain intact.”

Most web developers already understand the dangers in accepting unfiltered inputs in standard browser-based HTML forms, such as a user registration form. “However, mobile app developers oftentimes ignore this,” says Book. “They ignore it because they don’t understand how to filter inputs, or because they simply don’t consider the risk the same way they would when creating a browser-based app.”

The fix? “All inputs provided by a user in a mobile app should be filtered at the device level to prevent the intentional, or unintentional injection of invalid characters,” says Book. “A SQL injection attack is equally as likely when data is originating from a mobile app as it is from an HTML form; this must be considered when developing mobile software.”

5. User Data Saved to NSUserDefaults or SharedPreferences. Application developers often need to store small pieces of data on the device for later use. “In iOS this data is usually stored using the built in NSUserDefault class,” explains Book. “In Android this data is usually stored using the built-in SharedPreferences class. The problem with these approaches is that the NSUserDefault class and the SharedPreferences class stores this data on the device in plain text. You can easily see this data by examining the backup data for any app after syncing with a computer.”

“It would also be trivial to find this data on a device should it become stolen or lost,” Book says. “All sensitive data saved on the device should be stored in a secure location within the app’s sandbox. In the case of iOS, this should be done using the built-in Keychain class. The Keychain (in iOS and Mac OSX) saves this data securely. In Android, the solution involves encrypting the data prior to saving it using the SharedPreferences utilities.”

6. Forgetting to kill the session. Think web apps for smartphones are better than mobile apps? Think again. “Session management and lifetime may be an issue for Web applications running on smartphones,” says Hill. “Since the browser never truly exits, non-expiring cookies may persist for a very long time. Authenticated Web applications that may be used on a smartphone should have explicit session lifetimes defined.”

7. Forgetting to secure the back end. “There’s lots of hype around the latest vulnerabilities in mobile apps, but remember that just like other client-server applications, most of the technical and business risk inherent in an application exists on the server-side,” says Jacob West, CTO of Fortify Products within HP Enterprise Security. “Most mobile apps are developed as lightweight clients, often backed by legacy Web applications. Finding, fixing, and preventing vulnerabilities in the client code is important, but don’t lose sight of the steps needed to secure the backend.”

As things stand today, enterprise mobile apps are the best means with which to secure corporate data on mobile devices. That does not mean, however, that mobile apps are as good as they can be. Start by including security in the design from the outset and then double-check for security compliance flaws before you make the app available on your app store.

Tools alone do not catch security compliance problems so be sure to work from a comprehensive checklist too. Not sure your checklist is comprehensive enough? Think in reverse, i.e. think like a hacker or acquire people or a service that can do so. By specifically looking for hacking opportunities, you can identify measures to eliminate them.