The Mobile App Security Mantra: Don’t Trust, But Verify
Although the technological designs of mobile devices have much in common with non-mobile computer systems, there are substantial differences that need to be understood. Here’s what mobile app developers should consider about the threat vectors they need to protect against.
Security on Computer vs. Mobile Ecosystems
Smartphone hardware and software technologies are radically different from that of computers. In terms of communication, on a computer you have one external communication channel -- whereas on a smartphone you have IP connectivity, Bluetooth connectivity, Cellular Data connectivity, NFC connectivity and so on. In terms of an operating system, mobile OSs are substantially more “closed” than desktop, laptop and enterprise OSs.
While at first glance this might make a mobile OS appear more secure, it’s truly a double-edged sword when -- not if -- threats manage to penetrate the OS defenses. As Luis Blando, vice president of engineering at McAfee, explains, “once the mobile OS is penetrated, the products and systems that would otherwise be able to protect the device (such as those made by security ISVs) would be limited in the protective actions they can take within the OS guardrails, and that can prevent quarantining, pre-emption or even detection.”
The mobile ecosystem is also very different from that of regular desktop computing in the number of viable operating systems, the types of application delivery mechanisms, and established policies for application acceptance. In the desktop world, with a simple visit to a URL, a user can download and install a binary which can very well be infected. In the mobile world, application download and installation is done mostly through approved stores that curate the apps.
That said, these app store checks can create a false sense of protection. “When we recently checked the origin of infected mobile software, as reported by the MMS user base, we discovered that the majority had been downloaded directly from major app stores,” Blando notes. “And, in Asia, the use of specialized app stores, which may or may not have any curation or security checks on their catalog, is widespread. Don’t think that just because you’re using GooglePlay or another major app store that it’s a guarantee of safety.”
Possibly even more significantly, there are vast differences in the usage models for mobile and regular computing devices. Mobile devices are with you all the time, record your every move, log your every communication, and are a treasure trove of both personal and corporate information. Smartphones contain much more information than the average computing device; it’s your phone, calendar, address book, camera, music station, remote control, ATM, shopping assistant, and more. The fact that smartphones are incredibly valuable for information theft pretty much guarantees that the supposedly secure “defenses” built in via technology or ecosystems as explained above will sooner or later be overcome. “Smartphones are simply irresistible as targets,” says Blando.
Despite these huge challenges, “mobile applications are often not tested at all for security, or are not tested in as much detail as traditional web applications,” notes Brian Shura, Vice President at AppSec Consulting. “The security testing toolset that is available for mobile applications is not that mature. A thorough assessment involves a large amount of manual testing combined with some automated tools. Large financial companies have the resources to perform detailed mobile application security assessments, but the majority of applications available from the App Store most likely have never undergone a thorough security assessment.”
Mobile Developers Have to “Think Differently” About Security
Mobile developers need to adopt a mobile security mindset. Although, in many ways, mobile devices are computers and developers need to treat them as such, nothing on a mobile device eliminates the need for secure coding practices. All programs should sanitize input, only request the permissions that are absolutely necessary, and never store passwords or user data in clear text.
That said, mobile software does present new security challenges both from the point of view of secure software but also of protecting the user. Any mobile developer’s first priority should always be to protect the user. One key is to never let the illusion of security or safety suggested by either a closed OS or a single-user device fool you.
Mobile software developers need to keep in mind some new challenges on mobile devices:
• Network mobility: Mobile devices connect to many networks. Most users will connect to any open WiFi hotspot they can find as a method of reducing cellular data usage. This means that mobile software, even more than desktop software, must never trust that the network is secure. In addition to eavesdropping, mobile software developers should be wary of hostile networks that may attempt to impersonate servers or services. Apps should encrypt all network data and verify servers and services before sending authentication credentials.
• Device usage: Mobile devices are, well, mobile. Smartphones and other mobile devices go everywhere with their owners. They are also often taken out, used for a short time, and then set down. This means that they are also quite often lost or temporarily available to strangers. This frequent and on-the-go usage means that most mobile devices are not password protected. This is in contrast to laptops that are much more often password protected and are used less often and for longer stretches of time.
Mobile software that handles sensitive data should offer users the ability to separately lock the application or access to the data. Shura explains that’s why “developers need to take this into account and build their applications in a way that a stolen mobile device doesn’t lead to an application user account compromise. For the most part, this means ensuring that sensitive information, such as passwords, are not stored on the mobile device.”
• Screen size: Smaller screens display less data. Screen size needs to be factored in when presenting the user with secure data or data they need to verify. One example is the URL input and display field in a browser. Most desktop browsers partially rely on the fact that a user can see the entire URL in this field. This is one line of defense against phishing attacks. The URL field on a mobile browser is so small, though, that only a fraction of the URL can be shown. This hides relevant data from the user and creates a new vulnerability. Keep in mind the size of the screen so that verification data displays are short or the most important data are displayed first.
How Can App Developers Help Users Keep Private Data Safe?
While “in the past, developers of mobile applications did not have many resources to turn to for security guidance, that’s definitely starting to change,” says Shura. “OWASP (Open Web Application Security Project) now has a Mobile Security Project, which includes an OWASP Mobile Top 10 List of common vulnerabilities to avoid, Mobile Cheat Sheets for developers, and lots of testing guidance for people that are performing mobile application security assessments. I encourage mobile application developers to become familiar with the resources that are available on the OWASP website.”
Blando notes that, depending on the OS, there are also some specific issues to be wary of:
• Be careful creating services, as any application on the device may have access to it.
• Treat incoming intents as hostile input -- sanitize and check the data they provide before acting on it.
• Make sure files stored on the device are protected both with file system permissions as well as other data protection techniques like obfuscation or encryption.
• Assume the user already has root access to the device.
• Assume the phone is jail-broken. That's not to rely on jail-broken behaviors, but to write your software as if the user already has full access to the device instead of relying on the OS to provide sandboxing to isolate your data from the user's view.
The Bottom Line: Don’t assume anything. Don’t trust. Verify.
Additional developer guidelines can be found at the U.S. Federal Trade Commission website: Mobile App Developers: Start with Security.