OWASP Mobile Top 10 Vulnerabilities and Risks Explained

Have you ever wondered how mobile phones get hacked into? Questioned if the app you’re downloading and installing is safe? Or stared at your phone wondering if its been hacked? Then you’re not alone. And as our phones become fused to our bodies, we should aim to understand the possible security risks and vulnerabilities that the apps we use day in and out face.

Introducing OWASP

The Open Web Application Security Project (OWASP) is an online community of security specialists and developers who work to improve the security of software through its community-led initiatives to help build secure web and mobile applications. Within this article we will be focusing on the top 10 mobile risks and vulnerabilities identified in 2016 by the OWASP community and provide real-word examples of how these risks could impact users, specifically those that use these mobile apps for healthcare.

The Importance of Understanding the Mobile Top 10

Now before we begin, allow me to explain the relationship between a risk, vulnerability, and a threat. A threat is anything that can exploit a vulnerability, like an attacker listening in to steal sensitive information. A vulnerability would be a security weakness, such as an app using an insecure protocol for communication. And a risk is the potential for loss or damage that would occur if a threat exploits a vulnerability, like the loss of a patient’s sensitive data as well as their trust.

 It is important to understand the OWASP Mobile Top 10 vulnerabilities and associated risks, because in 2018 NowSecure, a mobile app security vendor, reported that 85% of the most popular apps found on Google Play and the App Store violated at least one of the OWASP Mobile Top 10. Furthermore, over 40% of those apps suffered from either insecure data storage, insecure communication, or had extraneous functionality.

OWASP Mobile Top 10 Vulnerabilities & Assoc. Risks

M1: Improper Platform Usage

Improper platform usage is defined as the misuse of a platform’s features or failure to use platform security controls properly. For example, an iOS app that stores its secrets (session keys, passwords, etc.) in the App Local Storage, instead of the iOS key chain. Having these secrets stored in the local storage instead of the key chain makes it easier for an attacker to potentially gain access to these secrets, as the local storage lacks the end-to-end encryption provided by the iOS keychain.

M2: Insecure Data Storage

Insecure data storage occurs when development teams are not aware that a user or specific process can gain unauthorized or unattended access to a mobile device’s filesystem, resulting in the user or this process being able to access any sensitive or private data stored on the device. Back in 2016, this risk came to light when it was discovered that the Quest Diagnostics mobile app, MyQuest, exposed the PII (Personally Identifiable Information) and PHI (Protected Health Information) of 34,000 patients through hackers leveraging an internal error in the patient portal Web API used by their mobile app.

M3: Insecure Communication

When data is sent over the mobile network, it must traverse both the mobile device’s carrier network and the internet. An extra layer is added when you consider a mobile phone’s use case which includes the Bluetooth communication between the app and any other wearable devices. As at any point between device communication you could be susceptible to an attacker inserting themselves and modifying or stealing your information. Therefore, it is important to consider insecure communication risks.

M4: Insecure Authentication

Also, unlike web connections, mobile internet connections are less reliable or predictable. Moreover, these apps must also provide authentication when operating offline. For this reason, apps that have poor or missing authentication schemes allow hackers to gain unauthorized access to their sensitive data or access to other applications. For example, if single-sign-on (SSO) is used for multiple apps and one of those apps uses an insecure protocol such as HTTP or SSL/TLS 1.1, then an attacker could potentially hijack this session and use it to attack the other apps using the same SSO connection.

M5: Insufficient Crypto

It is general practice to apply cryptography when data is at rest, as well as when it’s in transit from one point to another. Usually following this practice will lead to an app having a basic level of security. However, it is important to dig one step deeper and analyze whether the cryptographic protocol or algorithm being used is secure enough for the data being protected. As a result, development teams must understand the processes behind the encryption/ decryption functionality being implemented in addition to knowing if the algorithm being used is weak or insecure in nature. For example, in 2018 the Philips HealthSuite Health Android app, was found to use a weak encryption scheme making it susceptible to brute-force attacks, impacting the availability and confidentiality of their patient’s data.

M6: Insecure Authorization

Insecure authorization occurs generally due to the implementation of poor or missing authorization schemes that enable a user or process to execute functionality that they’re not supposed to, with an authenticated but lower-privileged account. In the mobile app space, it is important to not only address this, but also limit the app’s permissions to what is necessary for it to work (aka least privilege). For this reason, it is critical for development teams to be aware of the inherit permissions required by the libraries they use, in addition to what system level access is or is not needed.

M7: Client Code Quality

Poor code quality is typically exploited via malware, code injection, or phishing scams; and discovered by hackers through the use of code analyzers or fuzzers. As a result, this vulnerability primarily occurs due to bad programming practices followed by development teams that can result in being vulnerable to cross-site scripting (XSS), OS command injection, buffer overflows, and a lot more. Luckily, the best way to prevent this is by development teams using dynamic and static code analyzers to find these bugs. Furthermore, including security from the very start of development and continuing to involve security throughout the mobile app’s lifecycle will lower the cost and effort needed to ensure the security of apps.

M8: Code Tampering

An attacker will attempt to tamper with a mobile app’s code with the intention of re-packaging, re-distributing, or modifying the app’s core binary, resources, or API calls. Doing any one of these things could have a severe negative impact on users, exposing their data, app’s intellectual property, and putting users in harm. In January of 2016 Arxan Technologies, an IT security vendor, reported that most of the U.S. FDA approved health apps were susceptible to code tampering and reverse engineering - lacking binary protections. It is crucial to understand the environment in which our apps live, which is an environment developer do not control and thus cannot trust. Therefore, those that develop apps need to harden their code and ensure that proper security controls are in place to protect against advanced threats, such as detecting if a phone is rooted/jailbroken and taking appropriate action.

M9: Reverse Engineering

Reverse engineering refers to the process of taking something apart like a radio to see how it works. In the mobile app world, reverse engineering comes in the form of a mobile app’s source code being analyzed to determine how it works. Of course, when compared to taking a part a radio, being able to reverse engineer a mobile app seems like a fun project for millennials to do, to be able to relate to older generations. From a hacker’s perspective, being able to see the code, read through the code, and understand the code will allow them to look for comments left by developers, hardcoded values such as passwords or keys, or give them insight in how to exploit the application. For this reason, similar to dealing code tampering, development and security teams should ensure that their app is hardened and that protections are in place to prevent reverse engineering.

M10: Extraneous Functionality

Apps released to the public with redundant functionality are a major privacy and security concern. Through leveraging these functions, a backdoor can be created to any of the internal systems used by the mobile app, giving an attacker unauthorized access to potentially the user’s data and/or company’s internal network. Therefore, it is essential for development teams to examine thoroughly the app’s configuration settings, API endpoints, logs, as well as remove anything related to back-end testing, debugging, staging, or pre-production environments.