MASVS & MSTG: A Quick Guide To Mobile App Security

A quick and practical guide to exploring the MASVS and MSTG caveats of OWASP's top ten list, improving mobile app security

While dealing with mobile application security, we often hear of the OWASP Mobile Top Ten list, which lists the top ten security risks associated with mobile applications.

However, seasoned developers and testers might feel the list is inadequate. Let us look at some caveats to the OWASP Top Ten:

• It is a crowdsourced list of vulnerability categories.

• The list was last updated in 2016.
  

As developers, we would like a comprehensive set of standards that can be used to design applications. Likewise, security testers would like to test an application against a list of items using predefined methodologies.

To meet these needs, we can look at the OWASP Mobile Application Security Verification Standard (MASVS) and OWASP Mobile Security Testing Guide (MSTG), which provide information to facilitate secure application development and adequate testing.

OWASP MASVS

MASVS is an application standard for mobile app security. It helps developers develop secure mobile applications. Testers can use it to highlight relevant security risks.

This standard provides requirements for mobile application security, defining two security levels.

MASVS-L1 contains generic security requirements that are recommended for all apps.

MASVS-L2 contains requirements for defense-in-depth. Then, we also have MASVS-R, a set of reverse engineering requirements useful for providing client-side defenses.

Currently, the verification requirements are segregated into eight types. They are:

• V1: Architecture Design and Threat Modeling 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
  
  

V1-V7 provides requirements for MASVS-L1 and MASVS-L2. MASVS-R is a separate requirement.

Enforcing a control requirement is dependent on the business use case.

OWASP MSTG

MSTG is a comprehensive manual that can be used to test if an application fulfills the requirements outlined in MASVS. Likewise, Developers can use the manual to get an idea of how the application can be hacked.

MASVS has broken down its requirements into MSTG-IDs, which map to relevant test cases in MSTG. The Architecture section has other materials like secure SDLC and the OWASP Cheatsheet series. MSTG has tools and methods specifically designed to analyze mobile applications.

Understanding the MASVS verification Levels

MASVS-L1

MASVS-L1 is termed as standard security. It adheres to mobile security best practices and fulfills the basic requirements of code quality, handling sensitive data, and interaction with the mobile OS.

Drawing from MASVS 1.2, L1 Apps must fulfill the following requirements:

• MSTG-ARCH 1-4 and 12

  • All app components are identified and needed.

  • Security controls are enforced on both the server and the client.

  • A high-Level Architecture has been devised, and its security is accounted for.

  • All sensitive data for the business case has been identified.

  • The app complies with relevant privacy laws and regulations.
    
    

• MSTG-STORAGE 1-7

  • System Credential Facilities are used to save sensitive data.

  • Sensitive Data is not stored outside the credential facilities, not logged, not shared with third parties unless part of the architecture, not exposed to IPC mechanisms, and not exposed through a user interface.

  • The keyboard cache is disabled while handling sensitive data.
    
    

• MSTG-CRYPTO 1-6

  • The app doesn't rely solely on symmetric cryptography with hardcoded keys.

  • The app uses proven implementations of cryptography.

  • The app doesn't use deprecated standards.

  • The app doesn't use the same key for multiple purposes.

  • The app uses a high-entropy RNG.
    
    

• MSTG AUTH 1–7 and 12

  • Authentication and Authorization are performed on the remote endpoint. A password policy is present at the remote endpoint.

  • Stateful sessions should associate the client with randomly generated session identifiers.

  • Stateless authentication tokens should be signed using a secure algorithm.

  • Sessions are invalidated after tokens expire.

  • On Logout, the session should be terminated remotely.

  • Remote Endpoints are configured to disallow multiple login attempts.
    
    

• MSTG-NETWORK 1-3

  • Use TLS with recommended best practices.

  • Verify X.509 on the remote endpoint. Trust verified CAs only.
    
    

• MSTG-PLATFORM- 1-8

  • Manage permissions properly.

  • Sanitize external inputs, viz., data from external URLs and intents.

  • Avoid exporting sensitive functionality.

  • Disable JS in WebView.

  • Restrict protocols in WebView.

  • Restrict Native code access to JS in the app package.
    
    

• MSTG-CODE 1-9

  • The app is signed with a valid certificate and a private key.

  • The published build is in release mode.

  • Debugging symbols have been removed.

  • Third-party libraries and components have been identified and tested for vulnerabilities.

  • By default, access is denied.

  • Security features offered by the toolchain are used.
    

Enforcing L1 requirements doesn't have a significant impact on the SDLC. Depending on the business and use cases, employ L1 requirements in all apps.

MASVS-L2

MASVS-L2 is termed defense-in-depth. To fulfill L2 requirements, a threat model must exist. Security should be part of the app's life cycle. For example:

• A separate secure life cycle has to be defined for sensitive data.

• 2FA is enforced mandatorily. Certificate Pinning is enforced.

• Custom keyboards are blocked from accessing sensitive data.

The following requirements are necessary for L2 apps (we highlight the ones above the L1 requirements):

• MSTG-ARCH 1-12

  • The app components should be defined in terms of business and security functions.

  • A threat model for the mobile app should be defined, including recording countermeasures.

  • A separate policy for cryptography should be established.

  • A mechanism for enforcing updates should be implemented.

  • Security should be addressed across all components.

  • A responsible disclosure policy should be in place.
    
    

• MSTG-STORAGE 1-15

  • Sensitive data should not be present in the provided backups.

  • The app removes sensitive data when it moves to the background.

  • The app doesn't hold sensitive data in memory for long. Memory should be cleared explicitly after usage.

  • The app should enforce a minimum device security policy, like setting a passcode.

  • The app educates the user about the sensitive data it uses and the security best practices it follows.

  • Sensitive data should not be present on the phone. It should be stored at a remote endpoint and retrieved from the endpoint.

  • If sensitive data needs to be stored on the mobile device, it should be encrypted with a key derived from hardware-backed storage that requires authentication.

  • The app's local storage should be wiped out after multiple unsuccessful attempts.
    
    

• MSTG-CRYPTO 1-6

  • Same as L1.
    
    

• MSTG AUTH 1-12

  • Biometric Authentication should not be event-bound.

  • 2FA is consistently enforced.

  • Sensitive transactions require stepped-up authentication.

  • The app informs the user about all sensitive activities in their accounts. Users should be able to see all logged-in sessions, locations from where a device logged in, and device information for logged-in users.

  • Controls for blocking devices should be made available to users.
    
    

• MSTG-NETWORK 1-6

  • The app uses its certificate or pins an endpoint certificate. The app doesn't trust an endpoint with a different certificate.

  • The app doesn't rely on a single insecure communication (email or SMS) for operations like enrollment or account recovery.

  • The app depends on updated, secure libraries.
    
    

• MSTG-PLATFORM- 1-11

  • The app should protect itself against screen overlay attacks.

  • WebView's cache, storage, and resources should be destroyed after a WebView is destroyed.

  • The app prevents the use of third-party keyboards when a user is entering sensitive data.
    
    

• MSTG-CODE 1-9

  • Same as L1.
    

L2 has a considerably high development overhead. Such requirements are usually applicable to financial services and healthcare apps. These domains require certain compliances (HIPAA, PSD2, and PCI-DSS).

The MASVS-R is an independent level for client-side attacks, but an L2-compliant app should employ the R level.

One of the requirements of L2 is to threat-model an application. And client-side security should be a part of that threat model.

MASVS-R

The MASVS-R is a specially defined level for defense against client-side attacks like tampering, modifying, and reverse engineering. As such, an application should:

• Detect rooted or jailbroken devices and emulators.

• Prevent debugging.

• Detect application and asset tampering.

• Verify client integrity.

• Identify popular dynamic analysis tools like Frida and impede them.

• Have multiple strategies to achieve the points above.

• Employ device fingerprinting.

• Impede static analysis through encryption and obfuscation techniques.

• Have solid, hardened communication strategies.
  

MASVS-R can be used with L1 or L2 controls. We can safely assume an L2-compliant app already employs MASVS-R controls.

There are some unique cases when you don't need sensitive data management but require client-side security. Let's see some of the use cases:

• Games: Hackers like to target the Gaming industry, as it is a booming industry full of opportunities. You can see unique and aggressive client-side defenses in games like Pokemon Go and Fate Grand Order.
  

• Mobile apps that require client-side IP protection, like apps interfacing with hardware such as IoT devices, biometric devices, wearables, etc.
  

• Business use cases that require offline functionality. For offline apps, client-side security has to be thought out extensively.
  
  

Framing MASVS to Cross-Platform Frameworks

Cross-platform frameworks allow developers to develop applications for both Android and iOS using a shared codebase.

Popular cross-platform frameworks include React Native, Ionic, Cordova, Flutter, Xamarin, NativeScript, and Unity (for games).

MSTG covers cross-platform frameworks rather briefly. However, it’s recommended to test them as Native Apps. This makes sense from the standpoint of a tester, but it's problematic from a developer's perspective. We will be considering JavaScript frameworks.

One of the selling points of cross-platform frameworks is that we can leverage existing web technologies to develop an application on multiple platforms. A developer doesn't need extensive knowledge of native code to create mobile apps.

While there are good practices outlined in the documentation, to develop a secure solution, a developer needs a deep understanding of web technologies and native platforms.

We have outlined some good practices in our guides to Secure Ionic and Securing React Native. If you’re working with either of these frameworks, follow these guides.

Some security controls outlined in MASVS have to be enforced as native code. This adds quite a bit of overhead while developing the applications.

Develop a security model based on MASVS with WebView risks and utility overhead. Then proceed to development.

Addressing MASVS-R with Jscrambler

MASVS-R outlines security controls that must be implemented in mobile applications that are especially critical. Examples include mobile banking apps, fintech services, healthcare apps, apps with in-app purchases, and mostly every client-facing app that handles sensitive user data or contains proprietary logic.

Jscrambler addresses the client-side security requirements of MASVS-R. Specifically, it:

• Allows detecting rooted or jailbroken devices and triggering countermeasures to prevent the app (or some app features) from running on these risky devices.
  
  

• Actively prevents debugging and tampering, using a Self-Defending feature that scatters integrity checks throughout the code and breaks the app when a debugger is opened or the source code has been tampered with.
  
  

• Allows to prevent tampering attempts at runtime without disturbing the user experience, using a Self-Healing feature that uses checksum techniques to verify the app’s integrity and guarantees that only the correct code is executed.
  
  

• Ensures the integrity of the client environment by providing a series of Code Locks to only allow app execution in allowed domains, browsers, OSes, and timeframes.
  
  

• Includes a Code Hardening feature that prevents the usage of reverse engineering tools and is constantly updated to cover new versions of these tools.
  
  

• Provides state-of-the-art obfuscation with a combination of 20+ transformations like control flow flattening, string concealing, and identifier renaming, which provide maximum potency and resilience.
  
  

• Provides polymorphic behavior, ensuring that each new deployment of protected code is different but works like the original code.
  
  

• Includes specific features to protect sensitive data, such as Memory Protection for ciphering sensitive data when not being used by the app.
  

You can directly test these transformations in your code with a free Jscrambler trial.

Plus, you can use Jscrambler to protect JavaScript, C/C++, Objective-C/C++, Java, Swift, and Kotlin.

If you are working with a hybrid framework, check out the integration tutorials for React Native, Ionic, and NativeScript.

Final Thoughts

This was a brief overview of what OWASP MASVS and MSTG can offer to mobile app developers and testers.

Do you have specific security concerns?

Request a product demo or a quick meeting with one of Jscrambler's Application Security Experts.