The Open Web Application Security Project (OWASP) is a worldwide non-profit organization that frequently publishes practical information on application security. OWASP has published the “Top 10 Mobile Risks”, a list dedicated to securing mobile applications.
The practices referenced address insecure communication, weak authentication, tampering, reverse engineering, etc. They are classified by exploitability, prevalence, detectability, impact and come with guidelines for mobile developers looking to make their apps more secure. Developer security awareness is, therefore, one of the most effective components in building secure software.
If not identified and fixed prior release, these 10 mobile risks can lead to information theft, fraud and reputational damage.
Pradeo Security Mobile Application Security Testing tool identifies OWASP mobile risks, ranks them by severity and provides recommendations to fix them.
M1 - Improper platform usage
Mobile applications are developed through mobile app development platforms that offer various security features for developers to embed in their apps. Sometimes, developers simply choose not to use any of these features, while some others risk misconfiguring them by not entirely following the related documentation. As a result, security breaches often occur from the failure to use or the misuse of Android intents, iOS TouchID, iOS Keychain and other security functionalities. To prevent those, developers are advised to practice secure coding and configuration on the server-side of the mobile application.
Example: Citrix Worx apps
M2 - Insecure data storage
This second category includes vulnerabilities that can result in data leakage. From a security point of view, applications should not be designed to store sensitive information on the end-user side such as SDCards, applications files or local SQLite databases, especially when unencrypted. Besides, this category also encompasses bad practices such as having sensitive information written in the application logs, in the applications memory or its decompiled code, which of course should never be done.
Example: Tinder
M3 - Insecure communication
A mobile application usually exchanges data with several servers. When these communications over the network are not encrypted nor correctly authenticated (poor handshaking, incorrect SSL versions, weak negotiation, clear text communication, etc.), they can be intercepted by third parties. In the case of applications handling personal data (banking, health, public service…), these vulnerabilities represent a failure to comply to data privacy laws. On the other hand, when found in apps related to connected objects (home automation, security camera, smart cars…), they can lead to control takeover.
Example: Misafe smart watches
M4 - Insecure authentication
This category covers the authentication of end-users and bad session management. In mobile apps unlike in web apps, users are not always online. Hence mobile apps must be able to identify the user and maintain its identification along its session, when both online and offline.
When cybercriminals identify inexistent or weak authentication scheme in mobile apps, they create malwares that will bypass them. Strong user authentication that leverages multiple factor prevents them from accessing users’ data.
Example: Grab Android app
Get an overview of mobile app security techniques to implement from development to operations in our mobile application security guide.
M5 - Insufficient cryptography
Insecure use of cryptography is common among mobile apps leveraging encryption. It can come from flawed process or encryption algorithms that are weak by nature. In both cases, someone can exploit the vulnerability to decrypt sensitive data handle by the apps. Developers should make sure to apply the latest cryptographic standards that will withstand the test of time.
Example: App sending unencrypted user data
M6 - Insecure authorization
Some apps, after authenticating users, grant them some authorizations by default. These authorizations are sometimes mistakenly too extended, providing users with rights they should not have. If a cybercriminal gets access to privileged rights in an application, it can result in unlawful access to sensitive information, the deletion of entire systems or even the takeover of connected objects. The spectrum of authorizations granted to users should be assessed prior apps are released.
Example: Viper smart start
M7 – Client code quality
This category includes vulnerabilities like buffer overflows, format string vulnerabilities, and various other code-level mistakes that allow code to be executed on mobile devices. In case of a buffer overflow for instance, it is possible to write into areas known to hold executable code and replace it with malicious code, or to selectively overwrite data pertaining to the program's state, therefore causing behavior that was not intended by the original programmer. Most code issues can be fixed with good practices. Having code patterns across your organization that are easy to read and come with clear documentation is a good start to reduce this risk.
Example: WhatsApp
M8 - Code tampering
Tampering consists of duplicating an application, adding one or several back doors to its code, re-signing it and publishing it to third-party app stores. Tampered apps are often referred to as malicious clones, and usually target banking and very popular apps. Thanks to the back doors, hackers are able to intercept data and even sometimes impersonate official apps to communicate with companies’ servers. To prevent this risk, developers should use anti-tampering solutions and enable apps with capabilities to detect tampering.
Example: Postbank Finanzassistent (case study at the end of the article)
M9 - Reverse engineering
To reverse engineer an app, an attacker analyzes its binary code to determine its source code, libraries, algorithms and any other asset. By providing deeper knowledge on the app, this technique enables hackers to identify its flaws and exploit it more easily. Reverse engineering can result in the theft of intellectual property, information about backend servers, cryptographic ciphers, etc. To minimize this risk, developers must write complex code and use obfuscation.
Example: Pokemon Go
M10 - Extraneous functionality
During development cycles, developers often include hidden backdoors or security controls to their apps to detect and correct flaws. These functionalities are not supposed to remain in production environment, but sometimes accidently get forgotten. When identified by hackers, these features can be exploited to access sensitive data or escalate privileges. Before releasing an application, developers need to review configurations and should disable debug logs.
Example: Wifi File Transfer
