What is OWASP MASVS?

In case you didn’t notice, the OWASP Mobile Top 10 List was just updated, for the first time since 2016! This is important for developers since this list represents the list of the most crucial mobile application security risks in 2024. This blog explains how this fits in with other OWASP security guidelines, summarizes each of the 10 risks and discusses some possible next steps for developers. 

We have published a whitepaper with much more detailed information on each of the new Mobile Top 10 and how it fits into the other OWASP project OWASP MASVS “How to Use the 2024 OWASP Mobile Top Ten and OWASP MASVS to Secure Your Mobile Apps”.

OWASP Projects Focused on Mobile

The Open Worldwide Application Security Project (OWASP) is an online community founded in 2001 that has become highly influential in the realm of web, API and mobile application security. OWASP recognizes the unique security challenges of mobile apps, there are 2 key projects focussed on mobile security: 

• The OWASP Mobile Top 10: This provides a description and mitigation information for the 10 worst mobile application security vulnerabilities. The newly issued 2024 version updates the previous list, last published in 2016. 
• OWASP MAS: The second important OWASP project in mobile security is the MASVS (Mobile Application Security Verification Standard) which is intended to set the standard for mobile app security. MAS provides a valuable set of tools for mobile app developers. I wrote a blog about MASVS 2.0.

I’m Confused – Should I Use OWASP MASVS or the Mobile Top 10 to Validate my App?

At first glance it can be confusing. There is no explicit connection between OWASP MAS and then OWASP Mobile Top 10 and the versions of these documents are not coordinated.

Here is how to think about it: 

The OWASP MAS project consists of a series of documents that establish a security standard for mobile apps and a comprehensive testing guide that covers the processes, techniques, and tools used during a mobile application security assessment, as well as an exhaustive set of test cases that enables testers to deliver consistent and complete results.

The OWASP Top 10 on the other hand is really the reference standard for the most critical current mobile application security risks. Eliminating the OWASP Mobile Top 10 is perhaps the most effective first step towards changing your software development culture to one which is focused on producing secure code. 

There is a need for a short summary of the OWASP Top 10 for Mobile, so rather than wading through the OWASP documentation here is all you need to know to get started.

A more detailed mapping between the Mobile Top 10 and MASVS categories and guidelines on how to test and mitigate each one can be found in the whitepaper “How to Use the 2024 OWASP Mobile Top Ten and OWASP MASVS to Secure Your Mobile Apps”.

Summary of the 2024 OWASP Mobile Top 10

M1. Improper Credential Usage

Number 1 on the OWASP list concerns security of credentials, API keys and other secrets. Hackers can exploit hardcoded credentials and improper run time secret usage in mobile applications to gain unauthorized access to mobile app functionality. Also, stolen keys can also be used to access back end systems and APIs, by using publicly available or custom-built tools and scripts.

You should never store secrets in your app code and take steps to protect secrets at rest and in transit in the running app. In addition, ensure that you are able to routinely and quickly rotate any keys, especially third-party API keys.

M2. Inadequate Supply Chain Security

A ‘supply-chain attack’ is an attack on the external dependencies or tooling you use in order to introduce vulnerabilities, insecurities or malicious code into the app without being detected. It could be done by a rogue employee inside your organization, or in a piece of third-party code you employ, or even by a hacker who has gained privileged access to one of your systems.

You should monitor and check any third-party code you use, and sign your app code prior to distribution so that the app can be attested as genuine and unmodified at run time, and requests from modified apps can be blocked.

M3. Insecure Authentication/Authorization

Authentication and authorization are bundled together for number 3 on the OWASP list. For clarity, authentication is the act of verifying the user is who they say they are while authorization is the act of verifying the user has credentials to access a particular resource or level of service. Authentication concerns the theft and use of user credentials and then using these to either log on to the app or by directly accessing backend servers. Authorization issues are usually due to poorly implemented access levels to data and resources.

Again app attestation plays an important role. Run time integrity checks can detect any unauthorized code changes.

M4. Insufficient Input/Output Validation

Common vulnerabilities in APIs are caused by input data being modified by malicious agents. These types of attacks, including SQL injection, command Injection, and cross-site scripting (XSS) attacks are all permanent fixtures on the OWASP Top Ten or the OWASP API Top Ten. Unauthorized code execution, data breaches, data corruption or service interruptions are all possible consequences.

OWASP contains detailed guidelines on the testing and mitigation of the most common API vulnerabilities. An important second line of defense is to put in place the ability to block any requests that do not come from a genuine unmodified app. This can provide effective protection against the exploitation of zero day API vulnerabilities.

M5. Insecure Communication

This concerns the threats associated with the transfer or receiving of data. One of the critical attack surfaces in the mobile ecosystem is the API channel between mobile apps and backend servers. Man-in-the-Middle (MitM) attacks on this channel pose a significant threat to mobile users. If an attacker can gain control of the client, and even if SSL is employed, MitM attacks can occur through app repackaging or by using hooking frameworks like Frida to modify app behavior at runtime. It is important to assume that the network layer is subject to eavesdropping and that the trust store on the client device is open to manipulation.

Dynamic certificate pinning blocks MitM attacks and eliminates the operational burden of static pinning. It allows the pins to be updated on the server side without requiring app updates. In addition, dynamic pinning combined with app and client attestation prevents MitM attacks by manipulation of the mobile client.

M6. Inadequate Privacy Controls

A brand new entry at number 6 is ‘Inadequate Privacy Controls’. Privacy controls are concerned with protecting Personally Identifiable Information (PII),This information could be used by attackers for the purposes of fraud or blackmail. In general, PII could either be leaked (i.e., a violation of confidentiality), manipulated (violation of integrity) or destroyed/blocked (violation of availability).

Keep the amount and variety of PII that is processed to the absolute minimum and verify that the application is in compliance with privacy regulations such as GDPR and CCPA.

M7. Insufficient Binary Protections

App binaries usually can be downloaded from the app stores or copied from mobile devices, so binary attacks are easy to set up to steal intellectual property or modify the functioning of the app via reverse engineering or code tampering.

Using obfuscation to protect code can definitely slow attackers down and should be considered, especially as a means to protect IP from being used by competing apps. An important second line of defense is to employ run time protection and app integrity checks to identify and block apps which have been modified in any way. In addition, a means to quickly deploy and rotate API keys and secrets as described in M1 above is also a key element of the mitigation strategy.

M8. Security Misconfiguration

This is really the “other” category in the list. Security misconfigurations can happen in mobile apps due to factors such as time constraints, lack of awareness, or human error during development.

Preventing security misconfigurations in mobile apps requires following secure coding and configuration practices. Some suggestions are provided by OWASP, including taking particular care with default credentials and applying the “least privilege principle” for access.

M9. Insecure Data Storage

Hackers try to extract data for a range of nefarious purposes. Insecure data storage in a mobile application exposes vulnerabilities that threat actors can exploit. Exploits include using unauthorized access to the device’s file system, exploiting weak encryption, intercepting data transmissions, and leveraging malware or malicious apps installed on the device. Additionally, rooted or jailbroken devices provide an opportunity for attackers to bypass security measures and gain direct access to sensitive data.

Previously covered best practices all have a role to play here: implementing access controls and session management, ensuring strong encryption and secure data transmission, and keeping on top of third-party code and dependencies are all important. In addition, run time protections can block any hackers trying to steal data by manipulating the running app or the client environment.

M10. Insufficient Cryptography

Insufficient Cryptography is the threat posed to mobile apps by poor adoption of modern cryptography best practices. This could be through implementing algorithms that are deemed insecure or not using secure data transport (HTTPS). The attack vector for insecure cryptography in a mobile application involves exploiting vulnerabilities in the cryptographic mechanisms used to protect sensitive information, leading to data breaches or unauthorized access. 

Use established cryptographic libraries and frameworks with the strongest algorithms. . Always use HTTPS and make sure that encryption keys are securely stored on the mobile device and they are not in plain text or easily accessible locations. Keep up to date with NIST (National Institute of Standards and Technology) and IETF (Internet Engineering Task Force) guidelines.

Conclusion

In summary, App teams should integrate the OWASP Mobile Top 10 and MASVS into their entire development lifecycle, from initial design through development, testing, and maintenance. The OWASP projects together provide a comprehensive guide for implementing and verifying security in mobile applications throughout the lifecycle.

OWASP MASVS provides a comprehensive guide and set of tools to be used for implementing and verifying security in mobile applications throughout the lifecycle. See our blog about MASVS 2.0.

OWASP Mobile Top 10 can be used as an initial assessment to provide a high level measure of the robustness of your app. If any single one fails, it is a clear sign that you must, as a priority, dedicate more focus and resources to security.

Approov provides first and second level protection against the OWASP Mobile Top 10. Approov directly addresses M1 and M5 and because of its patented approach to app and client attestation, provides prevention of exploitation at scale of all the others on the list. Approov protects your mobile apps from being modified and prevents any manipulation of the client environment, keeps your API secrets secure, and protects the communications channel to the server.

Download our Whitepaper on Mobile Top 10 and MASVS categories and guidelines on how to test and mitigate “How to Use the 2024 OWASP Mobile Top Ten and OWASP MASVS to Secure Your Mobile Apps”.

*** This is a Security Bloggers Network syndicated blog from Approov Blog authored by George McGregor. Read the original post at: https://blog.approov.io/a-practical-guide-to-owasp-masvs-v2-0