OWASP Mobile Security: Top 10 Risks for 2017

When developing a mobile app, there are no better cyber security guidelines to follow then OWASP Mobile Top 10 Security Risks.

In the modern cyber security industry, you would be hard pressed to find people who didn’t hear about The Open Web Application Security Project or OWASP. They create written materials and tools to help spread knowledge and help fight various security vulnerabilities plaguing modern web applications for any large company and for startup alike.

In 2014 OWASP also started looking at mobile security. Their latest mobile OWASP top 10 was released in 2016 and is still pretty much very relevant. In this article, we will provide a brief overview of this vulnerability list for mobile platforms and will look at what the future has in store for OWASP and mobile security in 2017.

OWASP Mobile Top 10 – spreading awareness and helping bring security up across the board

OWASP started in 2001 as an online community focused on delivering unbiased and free analysis and guidelines on cyber security. Since then, their famous Top 10 Web Application Vulnerability lists have received near universal praise and endorsement from numerous specialists in the field of cyber security and largely considered to be the standard to adhere to.

Their lists help with security awareness and clue developers on where to look and what to prioritize in order to create more secure web apps. Custom cyber security tools and clear technical guidelines, such as OWASP mobile security testing guide, make OWASP useful and trustworthy for technical communities.

And when it comes to OWASP mobile application security list, it is based on data carefully gathered from vendors and consultants over the course of the year, that is then analyzed and distilled to the 10 categories that encompass most common and most severe vulnerabilities out there.

You can find the full description of each category at the official OWASP website, coupled with details and other useful information. Now, let’s look at these categories in more detail.

M1: Improper Platform Usage

Mobile platforms provide a number of features that developers can access. However, improper use of these features can leave your app exposed to attacks.

OWASP describes this vulnerability as common and easily exploitable. Of course, the actual ease of exploit and severity of the impact largely depends on the type of specific exploit and an extent to which perpetrator managed to gain control.

How can this be prevented? The most common attack vector here is any exposed API. Following rules and guidelines created by platform holders allow you to make sure that all platform features are used in a correct way.  Following common best practices when developing your API is also a key.

M2: Insecure Data Storage

M4: Unintended data leakage from OWASP Mobile top 10 risks for 2014 was merged with M2: Insecure data storage, creating the current category that kept the same name, but became much more clear and comprehensive.

The attack vector here varies greatly. From third party apps using cache, cookies and other information to gather protected data, to adversary being able to physically obtain the device and view information, you need to handle data storage correctly in multiple ways. This includes authentication, encryption, and properly handling all caching features.

What’s most important is that insecure data storage can be extremely easy to exploit. Privacy violations, as well as lost and leaked data are a steep price to pay for skimping on mobile security. Depending on the app, business impact can be quite severe.

M3: Insecure Communication

This is an extremely common vulnerability present in the majority of apps with client-server structure. While developers often diligent about protecting authentication procedure and data at rest, they rarely bother to encrypt data in motion.

By not encrypting data in transit, you subject your app to the man in the middle attack. Such an attack can typically come from a network device, such as a router, a malware on your own device, or even a separate agent sharing the same network as you are.

The best prevention method? Encryption and thorough verification of data. Employ SSL/TLS and prohibit self-signing certificates, using only trusted ones. Another great best practice recommended by OWASP is to apply additional encryption to the data before sending it.

All and all, when not using encryption, you open your mobile app to an easily exploitable vulnerability that can lead to data loss and bears severe impact on business.

M4: Insecure Authentication

This category encompasses both weaknesses in authentication procedure and session handling. For mobile apps, perpetrators usually create custom tools in order to bypass the client-side app entirely and submit a request directly to the server.

Authentication schemes for mobile apps are usually much more lean than for regular web apps. Since most apps will need to work offline, a user is provided with an offline authentication option that can be exploited.

This results in perpetrator gaining full control of the system. They can anonymously delete or steal data, or issue commands to the app or to the server, etc. This may lead to severe technical and business impact. Sadly, authentication vulnerabilities are both common and easily exploitable.

The best way to avoid this is to use online authentication whenever possible while processing all authentication requests server-side. It is also a good practice to reinforce authentication server-side and perform local integrity checks that detect any unauthorized code changes.

M5: Insufficient Cryptography

This category deals with the vulnerability that can have an extremely nasty business impact because it results in perpetrator obtaining decrypted information from a mobile device. Depending on the app, extremely personal information can be compromised, leading to user backlash and even potential lawsuits.

OWASP states that incorrect use of encryption is extremely common in mobile apps. Weak encryption algorithms, as well as flawed encryption/decryption procedure can be easily exploited.

The best way to avoid this is to follow the best practices and standards used in cryptography. For example, National Institute of Standards and Technology provides a set of guidelines on cryptographic standards for federal government. This is a great place to start with more secure cryptography.

M6: Insecure Authorization

On the first glance, this category may sound similar to M4. However, it is actually completely different as it deals with server-side vulnerabilities during the authentication procedure.

Vulnerabilities regarding authentication gained prominence in cyber security landscape as of late. They are extremely common and can be hard to detect, while also posing a severe business impact. This is why they gained an additional prominence in both OWASP Web Application and Mobile Top 10.

The best way to fight these issues is to make sure that user rights are always checked server-side. Avoid trusting any information about the level of permission that application gives you, as it may be compromised. You should also do your best to verify any requests from a client independently server-side, making sure that they belong to the authorized user.

M7: Client Code Quality

This category focuses on vulnerabilities created due to coding mistakes. No code is perfect and perpetrators can find those errors and exploit them to gain access to the system.

Perfect examples of this are buffer overflows and memory leaks. Letting a buffer overflow slip through testing can allow the perpetrator to gain control over the whole map, potentially leading to theft of private data, and even control over devise itself.

Luckily, severe business and technical impact are slightly offset by the difficulty of exploiting such vulnerabilities. However, this means that catching them can also be extremely hard for your own team.

The only good tip for dealing with such vulnerabilities is to maintain consistent coding standards across the board and to write a well-commented code that is easy to read.

M8: Code Tampering

This category covers any modifications that adversary can perform on the code of the app. There are a variety of ways to do this, including method/class hooking, dynamic hooking, patching, etc.

Perpetrators can use code tampering to gain access to premium features, violating copyright and completely bypassing existing distribution model for the app.

What’s even more important, is that they can add malware to the app via direct changes to the binaries, or to resources. Modified app is then distributed via third-party distribution platforms, resulting in lost sales and reputation damages for the original developers.

This vulnerability is fairly common and can be reasonably difficult to detect. The best way to fight it is to use anti-tampering techniques, as well as root and jailbreak detection.

M9: Reverse Engineering

Reverse engineering is extremely widespread and not always done with malicious intentions. Sometimes people do it to study, sometimes they do it to write their own completely legitimate apps.

But often perpetrators will use the technique to gain the information needed to exploit security vulnerabilities and decrypt data. Information on encryption algorithms used, as well as general workings of a back-end server are particularly critical to protect.

It may be obvious, but every app is susceptible to reverse engineering. And while the damage from it can often be limited, this is not a reason to not fight it. Using various tools to obfuscate the code is the best way to deal with reverse engineering.

If you’re interested in the topic, you can also check out our article on iOS reverse engineering for additional information.

M10: Extraneous Functionality

This category has been added to the list in 2016 in order to cover and extremely severe, yet surprisingly common vulnerability – functionality found in the app that shouldn’t be there.

This vulnerability arises when developers don’t remove additional features, created during the development process to make it easier to test the app. One example of such feature is a developer account that allows to completely bypass security checks and provides a wide set of privileges. It essentially is a backdoor that gives attacker full control over the app.

Such vulnerabilities are easy to exploit, but also easy to catch and remove. All you need is to verify that no test code is included in the final build of the app.

And if you’re specifically interested in testing Android solutions, check out our article that explains how to pentest an Android app.

The future of OWASP Mobile top 10

The current OWASP mobile security top 10 list is extremely refined and comprehensive. However, cyber security landscape constantly changes, mobile in particular. Both perpetrators and developers tend to adapt at a breakneck pace, and raising awareness of a particular issue can mean that more people will be ready to deal with it in the future.

Thus it’s extremely hard to speculate what the Mobile top 10 holds in the future. We will undoubtedly see the next one – OWASP already gathers data for it. However, the release will probably be in 2018.

As for 2017, the current list is more than relevant as is. Weak authentication and session handling, as well bad coding practices and insufficient protection for data at rest and in transit are extremely important.

All of this is something that we pay extremely close attention to when developing mobile apps for our clients here at Apriorit.