Compared to web applications, the mobile ecosystem is a young technology, but it is a growing and dynamic segment, developing at a breakneck pace becoming more and more popular each year. According to a recent report, it is estimated that first-time app installs during the first half of 2020 reached 71.5 billion installs. That is an increase of 26.1 percent year-over-year, giving even more incentive for businesses to develop an app service. These numbers are consistently trending upwards, resulting in ever-increasing numbers of mobile app users. Indeed, the number of mobile apps is also growing especially as sometimes the functionality of mobile applications exceeds the capabilities of web versions. Mobile development is thus much more dynamic, the process itself allowing the release of more features quickly. As a consequence of the fast-paced development of mobile apps, diverse types of vulnerabilities can occur.
To organize all the information about vulnerabilities, we employ a range of standards and requirements. One of the most popular and universally recognized is the OWASP methodology and classification.
There are three main OWASP documents to highlight:
- MASVS – Mobile Application Security Verification Standard. Here, you can find all the main requirements and standards to follow.
- MSTG – Mobile Security Testing Guide. This guide will lead you through the testing process so you can ensure that your app is compliant with the standards.
- OWASP Mobile Top 10 – The Top 10 Most Common Security Issues in Mobile Apps.
OWASP Mobile Top 10 had only 2 versions: one is dated 2014 and the latest version released in 2016. Yes, the classification is 6 years old, which might seem strange for such a dynamic field. In comparison, similar classifications of vulnerabilities for web apps are usually revised and released every 2-3 years. However, the OWASP Mobile 2016 version is still a relevant and up-to-date source for developers.
So, what are the most common types of mobile application vulnerability? OWASP Mobile TOP-10 indicates that these are:
- Insecure Data Storage
- Insufficient Cryptography
- Improper Platform Usage
- Insecure Communication
- Insecure Authentication
- Client Code Quality
- Code Tampering
- Reverse Engineering
- Extraneous Functionality
Insecure Data Storage
The most common type of problem is the insecure storage of sensitive data. In this article, by sensitive information or sensitive data, we mean any information that could allow an attacker to create an attack vector against a user. This can be user authentication data (passwords, cookies, etc.), tokens for accessing third-party resources, or personal information (phone number, full name, passport/contact details). This category can be divided into three large groups: credential storage, authorization information storage on third-party resources, and other sensitive information storage. There are numerous ways for hackers to gain access to this data: local or cloud backups of the applications, vulnerabilities that allow attackers to read internal application files, loss or theft of the device.
Insufficient Cryptography
To apply cryptography properly and not compromise your application security completely, you need to be clear about what data you are protecting and from whom. For example, your mobile application uses a database, and it contains a certain amount of confidential data. To protect it, you need to take a step back and build at least a few simple threat models. As a result, you will understand exactly what data you are protecting, and from whom.
There are several common problems connected to cryptography. One of the most frequently encountered problems is how and where to store encryption keys. Even when we protect data, we need to protect the encryption key as well, which is most valuable. Another frequent problem is the use of outdated algorithms: these can be both encryption algorithms and hashing algorithms.
Insecure Communication
Another thing that we often see is the absence or incorrect implementation of communication channel protection, namely SSL Pinning. With an SSL certificate embedded in the code, the application becomes independent of the device’s certificate storage. Compromising the trusted certificate database within the application code itself is not so easy. To do this, the attacker will have to decompile the whole application, remove the certificate and then recompile it. However, there’s a downside to attempting this – once an SSL certificate is embedded in the application code, it is not simple task to change it. Every time you change the SSL certificate it requires the release of an updated version of the app, one which is launched on application store, and then they have to hope that users will install/update it. However, if you order an SSL certificate for the maximum validity period of three years, you will have to do this less often.
Storage of extra files in the application
Also, there is another problem, though not as common, but one worth mentioning: the storage of unwanted data in applications. It happens that we come across various files that should not have been included in the release. For example, certificates from dev servers, test configs, and other information not related to the release. In addition to the fact that such files can bloat the size of the application, it also opens additional avenues for an attacker to compromise the application. The attack vector is usually based on several flaws in the application, and even such a minor thing can become yet another opportunity to act with malicious intent.
As we mentioned at the beginning of the article, the OWASP Mobile Top 10 version has not been updated since 2016, but it is still relevant. This means that today’s developers and testers are still repeating the same mistakes as 6 years ago. All the mistakes described above are well-known and well-described and are made mostly due to inattention or a lack of time for a thorough security check of each release. Another reason is that developers and security analysts view the application and its functionality differently, and they pay attention to different things than attackers do.
Most of these problems can be solved with the automation of security testing and training of security analysts and developers. Automation would minimize the possibility of human-factor mistakes allowing developers to devote more time to finding business logic mistakes or complex vulnerabilities that cannot be found by automated means. Learning to develop securely will allow you to preempt vulnerabilities when developing new versions of your product.