In March of this year, OWASP released their 2016 edition of the Mobile Top Ten. Now that organizations have had some time to get acclimated to it, I wanted to provide some of my thoughts on it.

OWASP got this one right. I really like the fact they divided session management into categories of Authentication and Authorization, and added a new m1 (Improper Platform Usage) which is a common category but was not covered in 2014.



The following is a high-level summary of each weakness and the impact of improper implementation of security features.

M1 - Improper Platform Usage

Mobile platforms provide a variety of different services from authentication, to secure data communication to storage of sensitive information on the device. This includes the use of key OS components like the TouchId, keychain, or any other security controls that the mobile operating system has in place for the application running on it. This category includes all of the vulnerabilities that could arise if the platform security is not used properly.

Failure to use these features could allow an attacker to steal sensitive data from the device or when the application interacts with the backend server. This could also allow an attacker to impersonate the user and perform malicious operations that could allow them to take over the application or the device.

M2 - Insecure Data Storage Combining

M2 and M4 from OWASP Mobile Top 10 2014, this category includes vulnerabilities that are related to sensitive data stored on the device in the application sandbox or on the SD card, or any data which is leaked by a side channel that the OS controls without the developer’s knowledge. The data stored by the device may be in shared preference property files, SQLite databases, cookie stores or simply just flat files. The OS on the other hand can leak the information by means of OS data or keyboard caches, unintended verbose loggings, pasteboard caching or simple URL caching.

If the insecurely stored data is stolen this could lead to privacy violation, identity theft and a sever reputation damage.

M3 - Insecure Communication

This category covers all the vulnerabilities that could allow an attacker to steal or modify the communication between two mobile devices, a mobile device and a server, a mobile device and any other hardware device, or between two servers. The channel used for communication can be TCP/IP, GSM, 3G, 4G, Bluetooth, NFC, Wi-Fi etc.

If an attacker performs a man in the middle attack, sensitive information can be stolen or modified during the communication without the end user’s knowledge.

M4 - Insecure Authentication

This category covers all the vulnerabilities related to user authentication or a weak session management. As a general rule, the mobile application should not have any less authentication capability than a normal web application. The device identifiers like Mac address, UDID, IMEI or any hardware identifier should never be used to identity the user’s identity or session. Secure session management policy includes non-predictable session tokens, a limited session lifetime and logs the user off in case of a possible attack.

If the session is compromised an attacker can gain access to sensitive user information or to perform operations that should otherwise be available only to restricted users.

M5 - Insufficient Cryptography

Applications often use encryption algorithms or encoding to protect sensitive data. This category covers all the vulnerabilities that arise when the application tries to encrypt/protect the data using some sort of encryption system but there exists a weakness in that system that could allow the system to be compromised and the protected data to be leaked. This includes vulnerabilities related to stored passwords, crypto and key implementations, as well as cipher strengths.

If there is a weak cryptographic implementation, an attacker can gain access to (or modify) the sensitive data that was assumed to be protected by the application.

M6 - Insecure Authorization

This category covers all the vulnerabilities related to the application where there is an authentication system in place and a user cannot access the application without proper credentials; however there exists a weakness in the system that allows an attacker to view the data that belongs to some other user. Insecure authorization is also the result of the server’s excessive trust on the client’s requests. If the server assumes that the all the requests sent by the client mobile application is proper and provides data without additional authorization checks, this could result in a severe data breach.

If the application does not perform proper authorization checks, an attacker can perform operations that they are otherwise not privileged to perform. This could allow a severe breach of confidential client data.

M7 - Client Code Quality Issues

Applications normally assume that the input coming from other sources are secure so they do not typically perform proper validation on this data. This category handles all the code-level issues that could exist in a mobile application. These issues include code that could allow buffer overflow, memory access issues or format string attacks that is specific to the programming language in use.

Though the vulnerabilities in this category are difficult to exploit, if an attacker is able to exploit it they can run unrestricted remote code on the user device and gain access to any information that is on the device. Exploitation also allows an attacker to read sensitive information like encryption keys, passwords and sensitive API information from the device memory.

M8 - Code Tampering

This is a blanket category that covers the vulnerabilities that could arise if an attacker could modify the existing application binary or local resource downloaded from the App store. This could include a variety of scenarios such as application patching, method swizzling, method/class hooking or dynamic hooking and manipulations.

If an attacker is able to perform a code bypass by means of application patching, they can gain access to premium features in the application or modify the application to contain malware(s) that could infect the end user.

M9 - Reverse Engineering

Reverse Engineering is one of the most common methods used for cracking applications and gaining access to the source code. Vulnerabilities that could allow an attacker to gain information from the binary that should otherwise be hidden or could allow privileged access in the application are extremely dangerous. This could include access to hidden methods, encryption algorithms, hardcoded secrets by means of tools like IDA Pro or Hopper.

Reverse Engineering allows an attacker to gain access to the intellectual property of the customer that could include source code, cryptographic constants, API keys, encryption algorithms, or even hidden future release features in the application.

M10 - Extraneous Functionality

This is a new category added for 2016. This vulnerability is the result of poor testing. During the development phase of the application, the focus is on features rather than on security. Due to this, developers often add backdoors in the application for a faster application and data access. These backdoors could be a bypassed multifactor check, a developer account, an account with privileged access or an account that could modify or add new data to the backend database without any access checks. This category covers all the vulnerabilities that could arise if these features are not disabled before the application goes live up on the app store.

These hidden functionalities and developer backdoors if found by an attacker can be leveraged to compromise the complete application and gain access to sections in the application that should otherwise have been restricted.

Get The Complete 2016 Mobile OWASP Guide

Protect your assets against the growing threat of mobile attacks. Learn more about the 2016 Mobile OWASP Top 10 and get helpful tips on how to protect your applications against common mobile attacks.