The 3 Most Common Mobile Application Security Risks

Considering our reliance on mobile applications for our day-to-day personal and professional lives, mobile application security should be taken seriously, but unfortunately isn’t always. Especially when you take into account the fact that many of us have apps that: control our home’s security, provide access to our banking and finances, contain personal images, videos, and more than enough personal information about a person and their family to do serious harm if it fell in the wrong hands.

So as we build mobile applications, just like with web applications, it’s critical that we think about security from the very beginning, regardless of whether we are building apps for iOS or Android.

But, where do we start? What vulnerabilities should we be concerned with, and how do we defend against them? 

OWASP created a top 10 mobile risks list to help with answering these questions. In this post, we take a look at the top 3 most common mobile application security risks from the OWASP list that have been found to be the most often violated in iOS and Android applications.

Note: this blog post is extracted from one of the lessons in our free Introduction to Application Security(AppSec) course. If you find it helpful, you’ll definitely enjoy the course!

What’s the OWASP Mobile Top 10 List?

If you’re not familiar with OWASP, they are a well-respected nonprofit foundation that works to improve the security of software through community-led open source software projects, hundreds of local chapters worldwide, and tens of thousands of members.

Through these community-led open source projects, they’ve created top 10 lists, including the OWASP Mobile Top 10 Risks. This list outlines what they consider to be the top risks facing mobile applications. 

While the latest list is from 2016, it’s unlikely that there has been that significant of a change, so don’t let that throw you off. In fact, considering how long the list has been published, the next few reports we’re going to examine will shock you.

Mobile Application Security Reports

According to a 2019 report by Veracode, 91% and 95% of applications for iOS and Android, respectively, have some sort of security vulnerability.

91% and 95% of aps for iOS & Android have some sort of security vulnerability
91% and 95% of aps for iOS & Android have some sort of security vulnerability


A different report by Micro Focus states that 88% of the mobile apps they tested had at least one critical or high severity security issue in 2018, which was up 20% from 2016, and roughly the same as 2017.

Mobile apps with >= 1 critical/high severity security issue
Mobile apps with >= 1 critical/high severity security issue


Keeping in mind that some of these flaws could be false positives or trivial and without any serious consequences, these are still scary statistics.

What’s even more scary and interesting, though, is how many applications have been found to violate OWASP’s top 10 mobile application security risks, which are well known, and as mentioned, not new.

Let’s take a look.

OWASP Mobile Top 10 Violation Rates

While the security issues from those prior reports are not necessarily only risks listed in the OWASP Mobile Top 10, separate research by NowSecure from 2018 tested apps in the App store and Google Play store to determine how many of those apps violated OWASP’s top 10 mobile application security risks. Using this report will help us find the 3 most common mobile application security risks.

They compiled the number of applications that their tests found to be violating at least 1 of the OWASP top 10 risks, and then broke them down by which of the risks were most often violated.

They found that 85% of apps violated at least one of the top 10 risks! 

% of times an OWASP risk was found in mobile apps
% of times an OWASP risk was found in mobile apps

Of all the tested apps, 50% had insecure data storage and almost the same number of apps used insecure communication. Not far behind is the discovery of extraneous functionality.

As we’ll see, those three risks are not necessarily the most difficult to protect against in mobile applications. The first step is knowing about them, and then the second step is to review and test for them.

So, let’s take a look at the top 3 most common mobile application security risks which are: Insecure Data Storage, Insecure Communication, and Extraneous Functionality, starting with the first.

The Top 3 Most Common Mobile Application Security Risks

Risk #1 – M2: Insecure Data Storage

OWASP page for reference.

Mobile data storage illustration


What is it?

In 2014, Tinder – a very popular dating application – was sending users’ exact locations in order to figure out which users were near your location. Except the location data was not encrypted properly, and so people figured out how to find this data on their phones and see exactly where other users lived. Not their finest moment!

That is just one example, but overall, insecurely storing data can result in:

  • Identity theft
  • Privacy violation
  • Fraud
  • Reputation damage
  • And other losses or damages

As the example illustrated, this risk is not just relevant if someone’s phone gets physically stolen. It can also get exploited by malware, or even more simply, by just looking at data stored on the phone.

Just because your application stores something in the keychain, SQL databases, cookies, SD cards, on the cloud, or anywhere else; you can’t assume that it is being encrypted by the OS or system. You have to assume the opposite and plan accordingly.

Why is it important?

In the case of this risk, the exploitability of attack vectors is easy because if an attacker gets physical access to the mobile device, they can simply hook up the device to a computer and, with freely available software, they can see all third party application directories.

They don’t even have to have physical access to your mobile device, as mentioned. They could create malware and modify the application to send them this information, or with the case of the Tinder app, all they would have to do is look for the information being transmitted to their own device!

The security weakness prevalence is — according to OWASP — common, and the detectability is average.

The reason for this detectability rating is because we can check that important data is being encrypted using similar tools that would be used to exploit the vulnerability.

We can (and should) also check which encryption libraries are being used to ensure they are strong enough and don’t have any known issues. 

Of course, never ever try to create your own encryption algorithms. Stick to proven ones.

These are a couple of ways that we can detect problems with stored data, but how do we know whether our mobile app is vulnerable to insecure storage, and how do we go about preventing this risk from becoming exploited? Let’s take a look.

Is your application vulnerable?

Determining whether your application is vulnerable, and preventing this risk, requires that you check how and where your important data is being stored. Again, don’t make assumptions that it is being encrypted – verify.

Your application may be vulnerable if:

  • You don’t have any common understanding (ie: documentation) about what data your application is processing and how it should be handled (Threat Modeling helps with this)
  • You aren’t testing that the sensitive data is being properly encrypted when stored, or deleted after being temporarily processed (think in terms of system cache)
  • You don’t have documentation and verification concerning where your data is going (ie: is it also going to 3rd parties? Where all is it being stored? Temporarily and permanently)

How can you prevent it?

One of the first steps you can take is to create a threat model if you don’t already have one.

By using threat modeling, you can determine what information your application and its APIs will be handling and how important it is to secure that information. 

Once you’ve identified where the data is being stored and you’ve identified what information needs to be securely stored, you can put together the correct security controls to implement proper data storage, and to verify that those security controls are being effective.

Because otherwise, you don’t have a reference of where to start and where to end your search for insecure storage. There are simply too many variables in most applications to approach it blindly.

OWASP lists the following as especially important to consider:

  • URL caching (request and the response)
  • Keyboard press caching
  • Copy/paste buffer caching
  • Application background tasks
  • Intermediate data (usually meant as temporary data)
  • Logging
  • HTML5 data storage
  • Browser cookie objects
  • Analytics data sent to 3rd parties

Ultimately, you know your application better than anyone else, so use the above to help you get started, but think through how your application uses data and go from there!

Example attack scenarios

We can see example attack scenarios, and we can see the implications of improper data storage by using an application called iGoat which is maintained by OWASP and provides a learning tool for iOS application pentesting.

iGoat visualization

AndroGoat is a similar type of application, but for Android.

References

For additional references, we can check out:

Risk #2 – M3: Insecure Communication

OWASP page for reference.

Illustration of mobile communication


What is it?

Insecure communication has to do with how data is transferred because if improperly configured, attackers can intercept the data while it’s traveling and perform a number of attacks. This, of course, is why we often hear warnings of using coffee shop Wi-Fi.

Beyond untrustworthy networks, there are steps that we can, and should, take as app developers to properly encrypt data, so that even insecure networks don’t just deliver plain text data for attackers to exploit.

Why is it important?

The exploitability of insecure communication is labeled as easy by OWASP, even though the difficulty level can vary widely depending on where the communication is taking place. An open Wi-Fi at an airport will be easier to monitor traffic over than a carrier’s network.

The prevalence is labeled as common, and the detectability as average. The reason for this rating is because mobile applications frequently only use SSL/TLS when authenticating users, but not when making other requests or when transferring data.

This can expose all kinds of data including banking information, personal information, or even session IDs that can then be exploited.

The other danger is that encryption may be misconfigured, in which case the development team may think that the communication is secure, while in reality, it’s not.

Is your application vulnerable?

One of the important points made by OWASP is that there are multiple different communication channels for mobile applications, not just between your APIs and the mobile application, and not just through Wi-Fi connections.

It’s import for Bluetooth, NFC, 3G, audio, and any other type of communication technology that a mobile phone might use.

Illustration of mobile communication

Overall, if the data your application is sending or receiving can be tampered with in any way, without the change being detectable, then your application is vulnerable.

How can you prevent it?

One of the best ways to detect this issue is to monitor the phone’s network traffic while testing the application.

Of course, reviewing the application’s code and configuration is also important. Are the configuration settings correct, especially in production? Are sufficient encryption algorithms being used? Is the application checking for trusted connections before transmitting data?

These are all scenarios to test for in order to prevent insecure communication.

Example attack scenarios

Examples of possible attacks for insecure communication include MITM (man-in-the-middle) attacks, eavesdropping, and offline attacks (records information to attack it offline later).

Risk #3 – M10: Extraneous Functionality

OWASP link for reference.


What is it?

Extraneous functionality refers to (usually) accidentally or purposefully included functionality in mobile apps that typically doesn’t directly contribute to the application’s functionality, but instead is used during development.

For example, let’s say that developers include something extra when the application is in development or staging environments, but a flag is supposed to prevent it from being turned on in production.

Or, developers hide pieces of code to help them troubleshoot customer complaints — and those pieces of code grant them elevated privileges, which they believe won’t cause any harm since they’re the only ones who know about it.

Why is it important?

The problem with extraneous functionality is that attackers can sometimes exploit that functionality to their benefit. They can also do this, in some cases, in their own local environments. They can download and examine the app, such as log files, configuration files, or even the binary itself, and use local tools to extract information.

In doing so, they might find hidden switches, test code, or other beneficial information. That information or functionality can then be used to mount an attack.

As a result, the technical impact can be severe, since it can expose how backend systems work or provide access to high-privilege actions.

Is your application vulnerable?

Your app may be vulnerable if you include any sort of backdoor, information that could be revealed if someone evaluates the application, or any security controls that may get disabled during development and are supposed to be turned back on in production.

It can be very tempting to include backdoors into our applications in order to simplify the process for our development, customer support, or sales teams. Trust me, I know, because I’ve been there. But the problem with backdoors is that even if we think we’re the only ones who know about them, someone else can find and exploit them.

No matter how careful we are, talkative logs could expose a piece of information that could provide a trail for a curious mind to follow. Or seemingly innocent comments left behind can provide just enough of a clue.

Or, something gets modified in our DevOps pipeline that ends up leaving the wrong flag enabled in production, and all of a sudden certain endpoints or functionality that should be hidden and disabled can be accessed by crafty users.

How can you prevent it?

The best way to prevent creating vulnerabilities with extraneous functionality is to avoid pushing anything to production that doesn’t belong there, to maintain the principle of least privileges for users and resources, and to check our code for any functionality that could be exploited to provide elevated privileges.

As we explain in our Introduction to Application Security course, this is an area in which manual reviews shine. You can spend all of the money in the world on fancy tooling, and it could still miss a simple piece of code that could slip into production and cause major issues if it were to be discovered.

During the manual review, you should:

  • Examine the app’s configuration settings to discover any hidden switches
  • Verify that all test code (including comments) is stripped out in the production build
  • Examine all API endpoints use by the mobile app to make sure they’re pointing to the correct ones and are not leaking any sensitive information
  • Examine log statements to make sure there is no information leakage in production

Automated tools can definitely help with low hanging fruit, like enforcing that certain functionality be disabled, or certain secret information be removed before moving forward in the automated pipeline. So I’m not saying that tools don’t serve a purpose here, but we can’t just rely on them.

Example attack scenarios

Scenario #1: Imagine that there are two different endpoints used for accessing data in the mobile application. One of the endpoints is only meant to be used in development, and it contains elevated privileges. This means it could surface information that regular users should not have access to.

To prevent that from happening, developers set a flag so that the regular endpoint is the one used by the application once the mobile app is compiled and sent to users.

Despite that flag being used, the endpoint is still technically in the shipped code, and an attacker is able to find that privileged endpoint by analyzing the binary, and as a result, they’re able to gain elevated privileges and access restricted data.

Scenario #2: An attacker is able to access debug log files that provide information for the attacker to understand how the backend system works. While this itself is not necessarily a breach, the information gathered proved critical in helping the attacker breach the backend systems.

Remember: information gathering is a critical component of mounting a successful attack.

Closing Remarks on the Top 3 Most Common Mobile Application Security Risks

While we only explored the 3 most common mobile application security risks out of the top 10 OWASP list, being aware of the most commonly found flaws is a good starting point because it helps us understand what’s being neglected, and as a result, what’s most likely to be abused by threat agents.

To help you on your journey of building more secure applications, we’ve created a free Introduction to Application Security (AppSec) course as well as an ebook version! If you found this blog post helpful, you’ll definitely learn from the course.

Free introduction to application security ebook download
Download our free Ebook

Related Articles

Responses

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.