While dealing with mobile application security, we often hear of the OWASP Mobile Top Ten list - as its name implies, it’s a list of 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 of OWASP Top Ten.

• It's not a guide; it's a crowdsourced list of vulnerability categories;
• The list was last updated in 2016 and there are no immediate plans to update it.

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 enough info to facilitate secure application development and adequate testing.

OWASP MASVS

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

This standard provides a list of requirements an application should adhere to, 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 that is useful for providing client-side defenses. These levels will be explored in more detail in the next section.

Currently, the verification requirements are segregated into 8 types. They 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

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 in the form of MSTG-IDs. Each MSTG-ID in MASVS maps to a relevant test case in MSTG. The Architecture section includes references to other materials like secure SDLC and the OWASP Cheatsheet series. MSTG has a list of tools and methods specifically to analyze a mobile application.

Understanding the MASVS verification Levels

MASVS-L1

MASVS-L1 is termed as standard security. It adheres to mobile security best practices and fulfills basic requirements in terms of code quality, handling sensitive data, and interaction with the mobile OS. As of MASVS 1.2, it's recommended for L1 Apps to fulfill the following requirements

• MSTG-ARCH 1-4 & 12
  • All app components are identified and needed.
  • Security controls are enforced on both server and client.
  • 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 high entropy RNG.
• MSTG AUTH 1-7 & 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 Auth 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 of 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 with 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 against vulnerabilities.
  • Access is denied by default.
  • Security features offered by toolchain are used.

Typically, enforcing L1 requirements won’t have a significant impact on the SDLC. Depending on the business and use-cases, it's recommended to employ L1 requirements in all apps.

MASVS-L2

MASVS-L2 is termed as a defense-in-depth. To fulfill L2 requirements, a threat model must exist and security should be a part of the app 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 will be highlighting 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 application should be defined and possible countermeasures should be recorded.
  • 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 minimum device security policy like forcing the user to set a device passcode.
  • The app educates the user about the sensitive data the app 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.
  • In case 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 step-up authentication.
  • The app informs the user about all sensitive activities in their accounts. As in, users should be able to see all logged-in sessions, locations from where a device logged in, and device info of logged-in users.
  • Controls for blocking devices should be made available to users.
• MSTG-NETWORK 1-6
  • The app uses its own 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, 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 usage of third-party keyboards when a user is entering sensitive data
• MSTG-CODE 1-9
  • Same as L1.

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

While MASVS-R is a separate level for client-side attacks, it's safe to assume that an L2-compliant app should employ the R level as well. 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. That includes attacks like tampering, modifying, and reverse engineering. As such, an application should:

• Detect rooted/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 by encryption and obfuscation.
• Have solid hardened communication strategies.

MASVS-R can be used with L1 or L2 controls. As mentioned earlier, we can safely assume an L2-compliant app already might employ 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: Gaming is a booming industry that is traditionally targeted by hackers. 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 like IoT devices, biometric devices, wearables, etc.
• Business use-cases that require offline functionality. If you read the list, a lot of the security controls require an internet connection to enforce them. For offline apps, client-side security has to be thought out extensively.

Framing MASVS to Cross-Platform Frameworks

Cross-platform frameworks allow developing applications for both Android and iOS using a shared codebase. Some of the most 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 perspective. For brevity, we will be considering JavaScript frameworks.

One of the biggest 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 to have a very 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, make sure to follow these guides.

Even so, some of the security controls outlined in MASVS have to be enforced as native code. This adds quite a bit of overhead while developing the applications. So, it's recommended to develop a security model based on MASVS with WebView risks and utility overhead and then proceed to development.

Addressing MASVS-R With Jscrambler

As stated before, MASVS-R outlines certain 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 directly addresses the client-side security requirements of MASVS-R. Specifically, it:

• Allows detecting rooted/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 when the source code has been tampered with;
• Allows preventing 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, providing a series of Code Locks that can be used 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, which 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 identifiers renaming, which provide maximum potency and resilience;
• Has a polymorphic behavior, ensuring that each new deployment of protected code is completely different, but still works just like the original code;
• Has specific features to protect sensitive data, namely Memory Protection, which ciphers sensitive data when it’s not being used by the app.

You can directly test these transformations in your own code with a Jscrambler free trial. Plus, you can use Jscrambler to protect JavaScript, C/C++, Objective-C/C++, Java, Swift, and Kotlin.

In case you’re working with a hybrid framework, check 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.

We recommend that you check the Mobile App Security Checklist, which maps MASVS and MSTG as an Excel sheet.

In case you have specific security concerns, feel free to request a meeting with one of Jscrambler's Application Security Experts.