OWASP Mobile Security: Top 10 Risks for 2017

Security in the mobile development field is important as never before. There is a wild range of various threats that we don’t even think about. So many aspects are escaping our consideration while it’s our first duty to ensure that all of our app’s users will be secure and none of their personal data will be stolen. That’s why we decided to explore what is out there to teach us how to handle the security course.

It’s already an established fact that every developer should follow the OWASP research about the most common vulnerabilities and attacks regarding mobile and web products. Why is that? Well, the Open Web Application Security Project (OWASP) is a worldwide known charitable organization that made their mission to improve the security of software.

Among many of their achievements, there is an OWASP Mobile Security Project, that gives the mobile developers and security teams all resources needed to create secure mobile products. Started in 2010, it’s already proven worthiness, by building a mobile threat model and classifying mobile OWASP top 10 security risks. Based on this, their team provides developmental tools to reduce the likelihood impact of those risks. But the big project is still in progress – every year there is a new research and improvement to the list of the main threats to keep up with the industry trends and innovations. So, shall we take a few to check out what problems are ahead of us this year?

OWASP Mobile Security

OWASP Mobile Top 10 Risks: buckle up for a long ride

The one and only purpose of this list is to level up the mobile security and make it understandable for any freelancer or development company. The OWASP focuses at the application layer, testing an underlying mobile platform and inherent risks. They target the areas where an average mobile developer could actually succeed. In short, the OWASP Mobile Security explores the integration between the app, remote authentication services (Server Side Controls), and platform-specific features.

Last obtained results showed that some of the initial threats established in 2014 have been, in fact, almost beaten by talented developers, QA and security engineers. Their main course was to secure codes and server-side configuration practices and protect stored data and a transportation layer of the app. But the technological progress isn’t stopping, therefore, in 2016 some new risks were discovered.  

M1 – Improper Platform Usage (established in 2016)

Here we’re dealing with the misuse of a platform feature or failure to use platform security controls. Android internal storage, platform permissions, misuse of the TouchID, the iOS Keychain – all of that and more. It can be mobile operating system’s any security control.

What can be done as a preventive action? Be careful with the usage of a Keychain and Android intents.

M2 – Insecure Data Storage

This is a combination of insecure data storage and unintended data leakage, which applies to locally stored data along with cloud synced. The impact: loss of the data confidentiality, disclosure of the credentials, privacy violations, non-compliance. It’s generally a result of the encryption neglecting and caching of the information non-intended for long-term storage.  

What can be done as preventive actions? Identify and store only necessary data on the mobile device, and avoid public storage areas and query strings in sensitive data. Protect your data storage and password credentials by using containers and encrypted APIs.

Insecure Data Storage 

M3 – Insecure Communication

We are talking about poor handshaking (tokens sent during Wi-Fi connection), incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, etc. Lack of encryption for transmitted data usually leads to Man-in-the-Middle hacking attacks and tampering with the information in transit.

What can be done as preventive actions? You have to ensure that all of the valuable data that is leaving the device is encrypted. So, always validate SSL/TLS certificates and implement a secure network transmission of the sensitive data.

M4 – Insecure Authentication

This category represents poor authentication protocols, bad session management and issues with compromised tokens. This means failures to identify the user and to maintain his identity when it is required. All of it leads to a data theft or third-side tampering with it.

What can be done as preventive actions? Use a native keychain of the device or your own encrypted database for sensitive data storing. And if the app doesn’t need an offline access then just disable it. Also, learn how to disguise account numbers, handle tokens and create two-factor authentication.

M5 - Insecure Authorization

The difference between M5 and M4 is that this category includes server’s failures in authorization process like improper identity and permissions enforcing, authorization decisions on the client side and forced browsing. This usually ends in bad communication between the app and a back-end third-party.

What can be done as preventive actions? Here it’s recommended to ensure proper Server-Side SSL and web server configuration.

M6 - Insufficient Cryptography

Insufficient Cryptography

The code must apply cryptography to a sensitive data, but this category represents issues when cryptography was attempted but wasn't done properly. The access to a sensitive information can be gained by some adversary due to insufficient data protection if the vulnerabilities impact the process of encryption/decryption or if the algorithm behind encryption/decryption is weak in nature. It can lead to private data violations, code theft or reverse engineering.

What can be done as preventive actions? Learn how to use the app platforms’ advantages like a native keychain to keep there all the sensitive information and do not ever store an encryption key in one place with the encrypted data.

M7 - Client Code Quality (established in 2016)

It used to be called "Security Decisions Via Untrusted Inputs", which combined all code-level implementation problems in the mobile client, like buffer overflows, format string vulnerabilities, and other code-related mistakes that allow rewriting mobile device’s code. As was proved by OWASP, bad quality of the code can allow hackers to exploit a business logic and bypass security controls implemented on the device.

What can be done as preventive actions? Three steps, actually, you should use carefully chosen logic, better not a simple one. Always test third-party libraries and validate client’s input.

M8 - Code Tampering (established in 2016)

Talking about binary patching, method hooking and swizzling, local resource modification, and dynamic memory modification. An enemy can directly modify the code, change the contents of memory dynamically or replace the application’s APIs, along with modifying the app's data and resources. Hackers can tamper with the existing backdoor or install a new one on the app, re-sign it and release a viral version to third-party marketplaces.

What can be done as preventive actions? Mobile developers and security engineers must learn and implement anti-tamper and tamper-detection techniques.

M9 - Reverse Engineering (established in 2016)

This means attacks on the final core binary to get a grip on the source code, cryptographic constants & ciphers, libraries, algorithms, back-end servers, etc. There are plenty of tools to do so very easily for even newbie hackers. Reverse engineering allows attackers to find out more about app’s functionality, therefore, identify some flaws they will exploit for their profit.

What can be done as preventive actions? Binary protection means making your code as complex as possible and using the obfuscation to prevent code leakage. Always store your code in a secure environment and take care of the correct use of jailbreak detection, and certificate pinning.

M10 - Extraneous Functionality (established in 2016)

It’s a fact, that the mobile developers really often include hidden backdoors in the app’s functionality or some internal security controls that are needed during a development process, but aren’t supposed to be released with a final product. It could be comments with passwords in hybrid apps or disabling of two-factor authentication during a testing phase. And when such actions are accidentally released into the bad hands... adversaries will, without a doubt, take a chance to tamper with / compromise an app.

Danger App

What can be done as preventive actions? Be careful with the debugger detection controls and pay attention while you manage debugging logs.

Okay, pretty much all the points are behind us. So, based on the OWASP Mobile Application Security Top 10 risks, the key focus areas can be easily identified for 2017:

  • Improper sensitive app’s data storage & Unintended data leakage
  • Weak encryption algorithms & Insufficient cryptography
  • Input bugs & Internal problems with third-party APIs
  • Lack of Binary protection (Reverse engineering attacks)
  • Code Protection from Extraneous tampering

And when you intend to create an application as a business idea for your startup, as an absolute must-read, we recommend making your bed-side book a comprehensive OWASP Mobile Security Testing Guide for iOS and Android mobile developers. Remember, that it’s your first and prior responsibility – to ensure the security of your product to keep your customers safe.

In that guide, you’ll find more info about mobile platform internals and testing in the secure development lifecycles, basic white-box and black-box security testing aspects. Along with the chapter on mobile reverse-engineering and code tampering, assessing software protections, and so on. You can download it here with testing tools and detailed howtos for iOS and Android.

Afterword

The OWASP Mobile Top 10 is a nice start for any developer or a security professional, but the road is still ahead and there is so much to do to destroy most of the possible doors that hackers can use to find out about app’s vulnerabilities. We’ll look forward for the OWASP to continue their work, but let’s not stay on the sidelines! If you have any ideas how to improve that list of risks above, please don’t hesitate to contact us and share the information. Let’s make our mobile world as secure as possible.  

Read Next

5 Best Ways to Prototype your Mobile Project
5 Best Ways to Prototype your Mobile Project
How to Build a Secure and Easy Mobile Payment app
How to Build a Secure and Easy Mobile Payment app
How Bugs in the API Can Tell You Users’ Credentials
How Bugs in the API Can Tell You Users’ Credentials
Mobile Application Security Checklist
Mobile Application Security Checklist
Don’t leave us hanging!
[email protected]
Get in Touch