OWASP Mobile Top Ten: Avoiding The Most Common Mobile Vulnerabilities

Another week, another mobile app fiasco. This time around, we learned how an IoT connected car can be controlled through the WiFi installed in the car, enabling Mitsubishi Outlander car owners – as well as attackers – to wirelessly connect to the car’s console, allowing them to do things like turn off the car alarm and mess with the car’s system.

 

Even tech giants as big as Apple have struggled with mobile app insecurity issues. Last September, the App Store was hit with its own security scandal when Chinese developers used unofficial versions of Apple’s developer toolkit. That move invited malware into apps that somehow passed through Apple’s security standards and were made available to the masses.

 

Technology is moving fast – perhaps a bit too fast, if we’re factoring in the ability of organizations to implement high security standards throughout the ranks. But slowing down is not a possibility – security cannot afford to lag behind.

 

There is plenty of evidence of both the difficulty and failures to secure mobile applications. Looking at the Ponemon Institute’s 2015 State of Mobile App Insecurity report, we begin to see the discrepancies between the number of applications introduced into the market, significantly increasing year over year – and the strikingly low security standards discovered in many of the apps.

 

In a market where over 127 billion free applications were downloaded in 2014 along with 11 billion paid apps – at a total market revenue of nearly $26 billion in 2013. And yet, organizations average only $2 million dedicated to application security awareness and testing. Any way you dice them, the numbers just don’t add up.

 

What Holds Back Mobile Apps?

 

There are many factors that lead to insecure mobile applications being released, yet they need to be overcome. Keeping insecure applications in your portfolio is a sure way for hackers to be able to find the weak link, and could do untold amounts of damage to any organization. So what keeps businesses from properly securing mobile apps? A huge issue in mobile app security is that there’s not one area that holds back mobile app security. There are MANY reasons that factor into organizations neglecting to properly secure their mobile applications, including the following:

 

  • Mobile security testing is done too late in the SDLC, leading to many security issues either quickly fixed or ignored altogether
  • The rush to release mobile apps leads many organizations to forgo any security testing
  • Quick and easy access to open-source components, including frameworks, without proper security analysis
  • Budget and talent restraints
  • Developers coding without sufficient security awareness, especially with newer mobile languages

 

The lack of developer awareness of secure coding standards along with lack of budget spent on mobile application security are two of the scariest issues. If those creating an application that could be used by millions of people lack the proper knowledge to ensure the apps’ security – and the organization employing them doesn’t invest in either their education or proper security testing, we’re in big trouble.

 

The Ponemon study echoes those sentiments. 77% of survey respondents said that securing mobile applications is a difficult task, and a full half of the organizations who responded indicated that they allocate absolutely no money to protecting mobile applications.

 

OWASP Mobile Top Ten Insecurity
Courtesy: Ponemon State of Mobile Application Insecurity Report, 2015

 

Perhaps even more alarming is the overall budget spent on developing mobile apps. That same study found that while organizations are spending an annual average of about $33.5 million on application development, less than $2 million is spent on securing those apps. That, along with the shortage of both security professionals and developers with security expertise mean it’s really no wonder there’s such a huge gap in the number of mobile apps and their level of security.

 

How To Ensure Mobile App Security?

 

In the past five years, mobile application security has become paramount for organizations developing apps to survive in the increasingly hostile world of mobile malware and hackers aimed towards mobile exploits. If you’re involved with developing, deploying, or marketing mobile apps, it’s time to shape up your mobile application security standards, if you haven’t already.

 

For one, you need to understand the basics of mobile application security and how to protect against the risks introduced to organizations through mobile apps. While based on many of the same principles as web application security, mobile application security opens up organizations to different risks which require both the development and security team’s attention. Platforms and operating systems create totally new risks for organizations, and a wider range of access points, including the devices themselves, create a wider attack surface than many web applications.

 

The perfect place to start is with the OWASP Mobile Top 10, a cornerstone for anyone involved with mobile application security. The OWASP Mobile Top 10 online resource offers general best practices along with platform-specific guides to secure mobile application development. Here, we dive into each of the ten most common mobile app vulnerabilities – and the best ways of avoiding them.

 

A Look at OWASP Mobile Top 10 Vulnerabilities: What the Risks Are & How to Prevent Them

 

OWASP Mobile Top 10 Risks
OWASP Mobile Top 10 Risks, courtesy owasp.org

 

M1: Weak Server Side Controls

 

What’s the risk?

As the most exploited security threat for mobile apps, weak server side controls can wreak havoc on applications – as well as the organization behind the app. The major issue with weak server side controls is that the application is communicating with an insecure backend, allowing unauthorized users to access data stored there.

 

Ensuring your server is secured is one of the most important focus areas when developing and deploying a mobile application, which ironically enough, essentially has nothing to do with your application. Yet if it’s number one on the OWASP Mobile Top Ten, you better make sure you’re taking note.

 

How to prevent them:

  • Never trust the client
  • Carefully design server-side controls to mobile devices
  • Never use client applications to enforce access control

 

M2: Insecure Data Storage

 

What’s the risk?

 

Insecure data storage vulnerabilities can also do a good amount of damage to mobile applications and the devices themselves, as it does in instances where a vulnerability in one mobile app opens up access to local files, exposing any sensitive data stored there. That includes access to passwords, authentication tokens, as well as any geographical, personal, and financial info stored in the application.

 

How to prevent them:

  • Disallow sensitive information to be stored in log files, where it could be uploaded to a computer from an iOS device
  • Encrypt sensitive files so that even if they are accessed, they’re unreadable

 

M3: Insufficient Transport Layer Protection

 

What’s the risk?

 

When applications fail to use SSL/TLS more than only during authentication instances or user outdated or improperly configured certificates, data can be easily leaked or exposed to interception, enabling attackers to take over accounts, most dangerously admin accounts. This is especially dangerous when apps are used over WiFi, enabling attackers easy access through simple Man-in-the-Middle (MitM) attacks. The client-server relationship in mobile apps needs to be carefully protected to prevent such attacks.

 

How to prevent them:

  • Keep a continuous eye on network traffic for instances of possible attacks
  • Ensure the application is properly configured to enable SSL/TLS throughout a user session or at least on especially sensitive data, always keeping in mind the business value of the data collected by an app
  • Keep your SSL certificate up to date and ensure it matches all the domains associated with your mobile app AND backend

 

M4: Unintended Data Leakage

 

What’s the risk?

 

Data leakage comes from all sorts of flaws possible in mobile apps. For example, we all love the fact that our apps quickly load back up after we’ve put them ‘to sleep’ in the background. Yet when we’ve exited them during, let’s say, a banking session, that data’s been screenshotted, opening up risks of that data being stolen if it’s sent somewhere unprotected.

 

Unintended data leakage comes from innocent-enough seeming things like debugging messages, data saved in the device’s clipboard, and even keystroke logging. It’s a common mobile app vulnerability because it’s so easily overlooked – but the consequences are less so. The Insecure Data Leakage page on the OWASP Mobile Top 10 remarks that the risks of this vulnerability include privacy and PCI violations, reputational damage, as well as fraud.

 

How to prevent them:

  • Restrict data collected by your device to only what it needs
  • Never store sensitive data in public places or anywhere on the device other than the device’s native keychain or an encrypted database
  • Understand and closely monitor how your application handles actions like copy-paste buffering, application backgrounding, browser cookie objects, URL caching and keyboard press caching.

 

M5: Poor Authorization and Authentication

 

What’s the risk?

 

Mobile apps can go in and out of wireless connectivity, requiring many applications to offer offline access, including authentication processes. This, among other ways apps show poor authorization and authentication protocols, can pose major risks, including attackers ability to gain access to admin accounts. Worse yet, because of their nature these attacks are incredibly hard to trace, allowing, in worst case scenarios, anonymous control of the application’s administrative capabilities.

 

How to prevent them:

  • If your app doesn’t need offline access, disable it
  • Implement two-factor authorization if called for the sensitivity of your application
  • Take advantage of services like Microsoft’s Access Control Service,  which offers mobile developers an easy way of authorizing and authenticating users outside of the app
  • Always use either the device’s native keychain or your own encrypted database to store sensitive info

 

M6: Broken Cryptography

 

What’s the risk?

 

If your cryptographic protocols aren’t up to snuff, attackers can decrypt any critical info stored in the app or on the device. Risks of broken cryptography include privacy violations, code theft and reverse engineering, and data theft.

 

How to prevent them:

  • Use the app platforms’ native keychain to store any sensitive data
  • Never store an encryption key with the encrypted data

 

M7: Client Side Injection

 

What’s the risk?

 

Especially for Android applications, which are downloaded and run completely on the client, client side injection vulnerabilities are another common issue organizations need to stay on top of. SQL injection and Cross Site Scripting (XSS) are both possible through client side flaws, which could lead to unauthorized access to sensitive data and attacker access to admin accounts.

 

How to prevent them:

  • Use a whitelisting approach for the best defense against XSS
  • Validate and encode all data stored on the device
  • If using SQLite, ensure user data passes through a parameterized query and monitor log files for odd behavior

 

M8: Security Decisions Via Untrusted Inputs

 

What’s the risk?

 

Some apps, like your favorite video messaging apps, allow connections to outside parties without requesting permission, called Inter Process Communication (IPC). When an app is poorly designed, it could be vulnerable to XSS, SQL injections, and a host of other attacks – all because the front door was totally unlocked.  Risks include attackers changing inputs such as cookies to override authentication and authorization protocols and gain access to – you guessed it – sensitive info.

 

How to prevent them:

  • Ensure all info sent to any third-party is validated and encoded – on the server
  • Disable IPC mechanisms if not required for your app
  • Never pass sensitive info through IPC mechanisms

 

M9: Improper Session Handling

 

What’s the risk?

 

When an app fails to log users out properly or fails to use secure protocols, you run the risk of enabling attackers open, easy access to user and business data, depending on the app and who’s using it.

 

How to prevent them:

  • Especially with high-value business or financial applications, log users out after a specified amount of time
  • Never use device ID’s as a session token as they never expire
  • Ensure use of strong, secure session tokens

 

M10: Lack of Binary Protections

 

What’s the risk?

 

Binary protections ensure that attackers can’t get their hands on your app through reverse engineering. When not properly implemented, a lack of binary protections  will allow attackers to make your app do things you definitely don’t want it to do, including modifying the app to disable or add certain functionalities, as well as snatching up any sensitive data stored in the code.

 

How to prevent them:

  • Never store code in insecure environments out of your control
  • Ensure correct use of jailbreak detection, certificate pinning and debugger detection controls
  • Monitor runtime code for anomalies in the apps activity

 

The OWASP Mobile Top 10 is currently in the midst of being tweaked for a 2015 release, which we’ll cover here once it comes out. In the meantime, we’ll turn it to you – what are you doing to help secure your mobile applications?

 

 

The following two tabs change content below.
Sarah is in charge of social media and an editor and writer for the content team at Checkmarx. Her team sheds light on lesser-known AppSec issues and strives to launch content that will inspire, excite and teach security professionals about staying ahead of the hackers in an increasingly insecure world.

Latest posts by Sarah Vonnegut (see all)

Jump to Category