Introduction to Mobile Security
Nowadays, having a smartphone in a pocket enables users to use various services almost everywhere at any given time. In the age of ever-improving mobile technology, the market grows more and more, benefiting from stable operating systems, good processing power and longer battery life.
Many applications and solutions migrate from desktop and web environments into mobile to compete for casual users who prefer to use services without even powering up their laptops. These services vary from controlling a home vacuum cleaner robot, using calory-counting applications, chatting to connect with friends, buying tickets for a bus to work, managing bank account, posting on social media… As we can see, the possibilities are limitless, but one thing is common. These applications handle user data.
User data in any application can differ, but stolen and leaked it can cause irreversible damage. To mention a few cases, it can destroy property, someone’s personal or public life, it can lead to attacks on bank accounts or blackmail.
The responsibility for users’ data falls on business owner who handles this data. Breaches and leaks can be fined under GDPR up to 20mln euro or up to 4% of the annual worldwide turnover of the preceding financial year – whichever is greater. This can be a huge blow to any company’s stability. But with some effort and invested funds, companies can protect themselves and try to mitigate threats for users of their applications.
This article was created to show where to look for guidelines about mobile security. All materials we present here are open-source documents. The first one presents threats to mobile applications. The second one is a set of requirements applications should meet to be considered secure. The final one is a manual for people who will verify if these requirements are being met.
Source of materials
To know if a mobile application is secure, we should know what can be wrong with it. There are many resources on this topic. One of the most known resources is from the Open Web Application Security Project, OWASP for short – the biggest non-profit foundation working to improve software security. This foundation, with chapters around the globe, runs various community-led projects. A part of them is dedicated to security of mobile applications. Of course, OWASP published many useful materials concerning software security for web applications, API or IoT, but our focus here is on materials regarding mobile platforms.
OWASP Mobile Top 10
This OWASP list is focused on flaws in security of a mobile application itself, without going into problems which can occur on the server’s side of the whole system and typical web application issues.
OWASP built it based on real-world data that was collected, analysed, and categorised. In the list, the flaws are described by threat agents, and the list includes information on how the flaws can occur and what impact they have – both from the business and technical perspectives. There are also short summaries on how to check if an application is vulnerable to a given risk, together with mitigation and exemplary attack scenarios. All this is completed with further references and links to online resources.
The 10 problems, or risks, mentioned, in the order of likelihood and severity, are:
1. Improper Platform Usage
This category consists of risks introduced by violating published guidelines or other conventions and common practices. Misuse of Android intents, permissions, keychain and similar introduce unexpected security vulnerabilities like Cross-Site Scripting, exposing data in iOS Keychain, etc.
2. Insecure Data Storage
Protection of data stored inside the device’s filesystem or sensitive information in data stores is one of the challenges which mobile developers face. Without proper protection, user data will be exposed when an attacker uses specialised tools or malware to inspect the device’s memory or storage.
3. Insecure Communication
Data transit in an application can be threated by malware, malicious networks, or network devices. Application development should ensure proper protection against eavesdropping by introducing appropriate encryption of transport channels which should use strong ciphers and certificates. Also, the application should avoid sending any sensitive data by alternate, less-protected channels.
4. Insecure Authentication
Authentication is a mechanism of identifying users. This category brings attention to the limitations of the authentication on mobile platforms due to input form factor, device capabilities and unreliable connection. These include weak password policies, storing credentials or shared secrets on the device.
5. Insufficient Cryptography
This includes poor key management, as even the best cryptography fails when keys are accessible or hardcoded in binaries. Another issue can be the reliance on built-in code encryption processes, usage of self-created custom encryption protocols or weak cryptography.
6. Insecure Authorisation
If authentication is identifying users, then authorisation is a mechanism that determines to which functionalities/resources they should have access to. Problems with recognising permissions of a user in a system can vary in results, from privilege escalation to insecure direct object references. Absence of checking what a user should be able to do can result in user executing functions not suitable for their designed role.
7. Poor Client Code Quality
This category contains various problems with client’s code, including buffer overflows and memory leaks. It is difficult for exploitation, but it can result in foreign code execution or denial of service.
8. Code Tampering
Code modifications and exploitation via malicious versions of applications hosted on third-party is a common problem on mobile market. The victim is often tricked into installing malicious version of a well-known application from an unknown source.
9. Reverse Engineering
The code of most mobile applications is written in languages (frameworks) with dynamic introspection at runtime, making the applications susceptible to reverse engineering. One of the possibilities to prevent this is making it hard for the attacker to understand its innerworkings by obfuscating the code of the application.
10. Extraneous Functionality
These vulnerabilities are directed at backend systems but involve analysing a mobile application. Using their knowledge about configuration, switches, left-over test code, unused variables and logs, an attacker tries to bypass security controls and hidden backend endpoints. At the same time, they gain knowledge about functionalities not visible in the user interface, passwords, and hardcoded accounts.
Other useful OWASP projects
Beyond OWASP Mobile Top 10 which is directly focused on the security on mobile apps, there are other useful OWASP projects which can be helpful when developing secure mobile applications.
These are the following:
OWASP Top Ten – a project focused on web application’s security issues. The issues it describes can occur not only because of various vulnerabilities, but also when some of the standards or best practices are omitted.
The latest OWASP Top Ten list officially released in 2019 includes:
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities (XXE)
- Broken Access Control
- Security Misconfiguration
- Cross-Site Scripting
- Insecure Deserialisation
- Using Components with Known Vulnerabilities
- Insufficient Logging and Monitoring
OWASP API Security – a list that covers OWASP API Top Ten 2019 vulnerabilities. This project focuses on securing one of the most invisible parts of a mobile application’s ecosystem – at least from the user’s perspective.
The list consists of:
- Broken Object Level Authorisation
- Broken User Authentication
- Excessive Data Exposure
- Lack of Resources & Rate Limiting
- Broken Function Level Authorisation
- Mass Assignment
- Security Misconfiguration
- Improper Assets Management
- Insufficient Logging & Monitoring
Mobile Application Security Verification Standard
After getting to know what the most popular mistakes are during development, the next step should be knowing what requirements for a modern mobile app are to consider it secure.
The OWASP Mobile Application Security Verification Standard (MASVS) can be a great source of this information. It offers two levels of security requirements (MASVS-L1 as baseline and additional MASVS-L2 as protection for applications handling high sensitivity data) with third level (MASVS-R) which hardens applications against client-side threats with a set of reverse engineering resiliency requirements.
The last level can be an addition to the first or second level, so there are four possible combinations. Considering which level to apply should be preceded by risk assessment which should be compared with the cost of introducing it. Sometimes, introducing some security measures could be simply not worth of time and effort in perspective of a given risk.
Below, there are examples for each level the applications should consider:
- MASVS-L1 – the level which all applications should achieve, a set of best practices with moderate impact on development cost and user experience.
- MASVS-L2 – applications with personally identifiable information (PII), credit card numbers or risk of fraudulent usage of data stored. Also utilised, when user’s funds are moved.
- MASVS-L1+R – all applications which want to protect their Intellectual Property, hardening it against tampering and reverse engineering, including games which want to protect their product against modifying and cheating.
- MASVS-L2+R – for applications which store PII and whose wide range of supported devices and operating systems increases the need for enhanced resiliency. Also, applications relying on client-side protection when using in-app purchases can benefit from anti-tampering and anti-reverse engineering mechanisms. Lastly – for online banking which handles users’ funds on device exposed to potential risk.
The MASVS specifies which requirements are necessary for each level. These requirements are categorised into 8 groups. First seven categories consider L1 and L2, while the eighth specifies requirements for “+R” resilience level.
These categories are:
- V1: Architecture, Design and Threat Modelling Requirements
- V2: Data Storage and Privacy Requirements
- V3: Cryptography Requirements
- V4: Authentication and Session Management Requirements
- V5: Network Communication Requirements
- V6: Platform Interaction Requirements
- V7: Code Quality and Build Setting Requirements
- V8: Resilience Requirements
As mentioned before, mobile applications are often part of a more complicated system.
Application Security Verification Standard (ASVS) is more general, not focusing on mobile applications. It can be very useful when the product is more complex and consists of API and a web-application beside the mobile application. This document has similar structure to MASVS, but there is no Resiliency level and levels vary from 1 (bare minimum) to 3 (for military, critical infrastructure and “health & safety” areas).
Categories of requirements in ASVS are as follows:
- V1: Architecture, Design and Threat Modelling Requirements
- V2: Authentication Verification Requirements
- V3: Session Management Requirements
- V4: Access Control Verification Requirements
- V5: Validation, Sanitisation and Encoding Verification Requirements
- V6: Stored Cryptography Verification Requirements
- V7: Error Handling and Logging Verification Requirements
- V8: Data Protection Verification Requirements
- V9: Communications Verification Requirements
- V10: Malicious Code Verification Requirements
- V11: Business Logic Verification Requirements
- V12: File and Resources Verification Requirements
- V13: API and Web Service Verification Requirements
- V14: Configuration Verification Requirements
As you can see, some categories are similar to those in the MASVS, but remember that the perspective of ASVS is different, less focused and it describes requirements for the whole possible system.
Gathering requirements for applications is not where the usefulness of MASVS and ASVS ends. They can not only be used as requirements source, but also for secure development training, as baseline for security testing methodologies and security checklists.
Mobile Security Testing Guide
Mobile Security Testing Guide maps requirements from MASVS into testing methodology. Every requirement has a corresponding section on how to approach testing and ensure that the requirements are being met. These sections are divided into three main categories, one general for mobile applications and one each for specific platforms – Android and iOS, with security overview, test cases and techniques.
For example, the V4.1 from MASVS is:
In MSTG, you can look for references of proper ID, in this case “MSTG-AUTH-1”. The ID appears two times in the “Mobile App Authentication Architectures” chapter (universal part for both platforms). First time in “Verifying that Appropriate Authentication is in Place” which contains steps to verify if proper authentication and authorisation are in place, and a second time in “Testing OAuth 2.0 Flows” describing best practices to follow and how to verify them. One more occurrence can be found in the “Local Authentication on Android” chapter under “Testing Confirm Credentials”. There, you can find the “Overview” section which explains how Local Authentication on Android works, the “Static Analysis” section with code snippets which help to indicate if functionality was introduced and in “Dynamic Analysis” on how to verify application in runtime.
In the document, one can also find information on how to set testing environments for both platforms, descriptions of tools used in verifications with proper repositories as well as further reading on the topic of mobile architecture and security. With more than 500 pages full of information, it can be very helpful for a security tester in a project.
In addition to this, the Projects Page on OWASP has MSTG Hacking Playground – iOS and Android applications made in an insecure way to present to the readers examples of vulnerabilities described in the Testing Guide.
Documents presented in this article can be very helpful and allow us to introduce security in mobile application with relatively small effort.
The first one, OWASP Mobile Top 10 will help you understand what threats can endanger your application’s security.
The second one, Mobile Application Security Verification Standard is a great source of requirements for various levels of security in application and it can also be used as checklist when assessing security state of the application. Requirements are clear, with every section linked to further reading where you can find implementation tips and cheat sheets on given elements of application and how to secure it.
The third one, Mobile Security Testing Guide is more a complex and heavy document, but is one of the best sources of knowledge on how to approach verification of security requirements mapped from MASVS.
All of these, after introducing them in development or testing process can significantly increase the security of your product. After all, a safe product means safe business and safe business means less risk of financial loss.