Five Common Mobile App Security Vulnerabilities And How to Fix Them

Mobile app security leaves much to be desired. That was the conclusion of a 2016 Hewlett Packard Enterprise (HPE) study which found that a staggering 96 percent of 36,000 mobile apps failed at least one of 10 privacy checks. Three years ago, a similar HPE study found that 97 percent of 2,000 apps reviewed held insecure private information. 

As mobile app usage continues its exponential rise, so does attention to security.

Nissan was the latest household brand stung by mobile app insecurity last month when it was forced to shut down an app for its Leaf electric vehicle after security experts showed how to use the app's insecure APIs to remotely control any of the vehicles' functions.

With that and more at stake, here are the five most common security vulnerabilities for mobile apps – and how you can remedy them. 

How the app communicates with server applications for data processing and business logic is a key component of mobile app security. Typically this communication is done via web services or API calls. Failure to properly secure these calls with secure programming practices is the most common vulnerability I see in mobile apps. 

Indeed, The Open Web Application Security Project (OWASP) - an online community of articles, methodologies, documentation, tools, and technologies in web application security - also lists this as the leading mobile app vulnerability. 

Vulnerabilities in this category include Cross-Site Scripting, weak or absent authentication, injection style attacks, and cross-site request forgery (CSRF). 

Securing APIs and web services requires knowledge of general web application security, and secure web programming practices will reduce or eliminate this risk on the server. Many of the possible vulnerabilities and mitigation strategies can be researched at OWASP (www.owasp.org). Static code analysis tools are available to spot many common security vulnerabilities, and these tools should be incorporated into the development lifecycle.

Even if the server itself is secure, any network traffic sent from mobile apps unencrypted can be intercepted and possibly used for session hijacking, CSRF and “man in the middle” attacks. These types of attacks can take place anywhere a mobile device transmits data, from the carrier network to the free WiFi at the local coffee shop. An attacker needs nothing more than an access point to intercept every packet sent to and from your app.

While designing and programming your app, assume that all network traffic to and from the app is being intercepted. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both of which are frequently referred to as “SSL,” are cryptographic protocols designed to provide communications security over a computer network. You can use SSL/TLS to secure all information transferred between your app and any server applications. 

Lastly, it’s important to adhere to SSL/TLS best practices. Require SSL chain verification; use strong cipher suites, and either alert users or halt app execution in the event of an invalid certificate to protect your network traffic. 

Because mobile devices are difficult to physically secure, any time data is stored on a mobile device, care must be taken to protect sensitive information. 

Unsecured data may result in vulnerabilities such as invasions of privacy, violations of the Payment Card Industry Data Security Standard (a proprietary information security standard for organizations handling branded credit), identity theft and fraud. Stored data may be accessed remotely by malware, or with readily available forensic tools.

Each device handles data storage differently. Developers must understand the implications of how data is stored, cached and accessed, not only on each specific device, but also within each development framework. Common data leakage vectors include event and data logging, copy/paste buffers, HTTP caching, HTML5 local and session storage, and cookies.

Any secure application deployed to a device that is outside of the developer’s control must include measures to prevent attackers from decrypting, reverse engineering, or modifying application code – and mobile apps are no exception. Failing to protect your app against code modification could result in unauthorized access, disclosure of confidential data and even piracy of the app itself. Once the app binary has been compromised, even the most stringent security measures can be bypassed with relative ease. 

Become intimately familiar with the ways in which your target platforms support binary protection. Jailbreak/debugger detection, code modification detection (checksum controls), certificate pinning, and code obfuscation are just a few of the ways to protect secure applications from unauthorized modification. A more extensive guide can be found at OWASP.

Mobile apps often need to function even when offline, and this unique requirement means authentication is often designed to be less secure than traditional server-side or web authentication – using four-digit PINs, for example, or storing password hashes on the device itself. In some cases, such as the recent Nissan Leaf breach, virtually no authentication may exist at all.

Design your app with the assumption that authentication can be circumvented by an attacker on the client-side and on the server. Make no assumptions about the authentication state of the user, and do not allow the mobile app to perform authorization logic on behalf of the server.

For security-sensitive apps that must authenticate and authorize the user entirely on the client-side (i.e. for offline use), ensure proper binary protection exists.

All of the actions detailed here will help you develop markedly more secure mobile applications.