The OWASP (Open Worldwide Application Security Project) MASVS (Mobile Application Security Verification Standard) is a valuable resource for mobile app developers seeking to improve the security posture of their iOS and Android applications. The standard is based on the collective knowledge of security experts from around the world and provides both a baseline and a benchmark for security requirements for mobile apps.
There are 3 key documents which can be downloaded from the OWASP site:
The team makes it clear that MASVS documents can be updated at any time, and there was a major refactoring of the recommendations culminating in V2.0.0 of MASVS which was released in the Spring of 2023.
MASVS has continued to evolve since OWASP first recognized the unique security challenges of mobile apps and published the first OWASP Mobile Top 10 in 2010. It has become much more comprehensive in its coverage and at the same time has been simplified and overlap between controls has been removed. Some content that was more about testing has been moved to the MASTG as test cases.
In the previous version of MASVS three levels were defined: L1, L2 and R. L1 was intended as a baseline, and L2 defined defense-in-depth requirements for “apps handling sensitive data”. The R level gave detailed recommendations to protect against client side threats.
As part of the MASVS refactoring, these levels have been eliminated from MASVS to create a more abstract set of security controls. The levels are however reappearing in MASTG as profiles to help prioritize the tests which correspond to controls in the MASVS. The rationale behind this is that the same control can lead to different tests, depending on the level (or profile) of security that the app needs. In this way, different tests can be applied based on the required security profile. For a given category in MASVS, for example, a financial app that deals with highly sensitive data will be tested to the L2 level, whereas a different app might require to fulfill only L1 level tests for the given category.
Coinciding with the MASVS 2.0.0 release, OWASP MAS relaunched the MAS Crackmes as part of its new website. This is a collection of Android and iOS mobile reverse engineering challenges.
The MASTG refactoring work is continuing through 2023 with an emphasis on automation and ease-of-use. MASTG test cases will be aligned with the new MASVS v2.0 controls and create what the MAS project calls ‘atomic tests.’ The current large MASTG test cases will be split into smaller, more manageable chunks. This will provide a more fine-grained and comprehensive view of MASVS testing supported by the MASTG and will make it easier to apply the new profiles (L1, L2, R etc.) to tests and map sets of tests to specific app use-cases.
In addition, MASTG profiles will be aligned with the NIST (National Institute of Standards and Technology) OSCAL (Open Security Controls Assessment Language) standard. This means that MASVS provides a more flexible and comprehensive approach to security testing and makes it easier to share and reuse the security controls between different security platforms and organizations.
One set of controls was completely removed in V2.2.0 of MASVS. This is because the team saw that the architectural guidelines and best-practices outlined in MASVS-ARCH are well covered on NIST.SP.800.218 and in the OWASP Software Assurance Maturity Model (SAMM) standards and there was no point in reinventing the wheel. An added benefit of this change is that now all the controls described in MASVS can actually be tested against - this was not the case with some of the governance and design recommendations in MASVS-ARCH.
MASVS 2.0.0 has been simplified and is intended to provide a complete view of the high-level set of controls which must be verified for mobile apps. This however means that developers can’t just use the MASVS 2.0.0 by itself. MASVS describes attack surfaces but does not describe how to test resilience against them.
The MASTG creates a complementary reference for secure application development and the checklist provides the link between controls and tests.
A good mobile app security testing methodology should cover all controls listed in the MASVS. Based on the type/criticality of the app, the developer/tester selects tests from the MASTG for each control. For every control in MASVS, there are pointers in the checklist to the relevant tests and checks in MASTG.
The newly relaunched MAS Crackmes also provide a great tool to gain and practice the knowledge required to effectively use the MASTG.
In summary, the OWASP MAS tools overall provide a manual and resources for mobile app security testing. This toolkit allows professional security analysts to verify the security of mobile apps.
The reworked MASVS application security model is divided into several control groups representing the most critical attack surfaces around a mobile application. It is important to note that it's not just “about the app”. The network and the client environment both present significant attack surfaces and MASVS addresses those.
Here is a summary of the MASVS 2.0.0 security control groups with a short commentary on what's new:
Each control group contains individual units labeled MASVS-XXXXX-Y, which provide specific guidance on the security measures that must be implemented to meet the standard.
The OWASP MASVS controls are especially relevant to two different types of vendors.
The first category are vendors who have products which implement the MASVS tests. Tools such as Guardsquare Appsweep or the NowSecure Testing Platform aim to facilitate and automate testing against the MASVS controls.
The second category are security solution vendors. As you seek to secure your mobile apps, the MASVS controls can be used to evaluate the effectiveness of security solutions. No vendor addresses all of the MASVS controls and all have different approaches. However, by selecting key solutions which work together, all of the MASVS controls can be covered and a high level of protection can be achieved.
It is therefore in the interests of enterprises to evaluate potential mobile security solutions against MASVS and in the interest of vendors to make very clear how their solutions fit with the evolving MASVS controls and recommendations.
The following section summarizes how the Approov solution implements MASVS. The full Approov/MASVS whitepaper can be downloaded here.
As a security vendor exclusively focused on the challenges of mobile security Approov addresses the key security challenges presented by mobile apps.
Specifically, the Approov solution provides comprehensive protection for the following MASVS controls: MASVS-CRYPTO, MASVS-NETWORK, MASVS-RESILIENCE. Let's look at each in more detail.
“Cryptography is essential for mobile apps because mobile devices are highly portable and can be easily lost or stolen. This means that an attacker who gains physical access to a device can potentially access all the sensitive data stored on it, including passwords, financial information, and personally identifiable information. Cryptography provides a means of protecting this sensitive data by encrypting it so that it cannot be easily read or accessed by an unauthorized user.
The purpose of the controls in this category is to ensure that the verified app uses cryptography according to industry best practices, which are typically defined in external standards such as NIST.SP.800-175B and NIST.SP.800-57. This category also focuses on the management of cryptographic keys throughout their lifecycle, including key generation, storage, and protection. Poor key management can compromise even the strongest cryptography, so it is crucial for developers to follow the recommended best practices to ensure the security of their users’ sensitive data.”
Approov can secure and manage any secrets that an app needs, including API keys for owned or third party applications. Rather than hardcoding these into your app, where they are always vulnerable to reverse engineering extraction, an app protected by the Approov SDK simply obtains them at runtime from the Approov cloud service. The API keys are never stored in the app nor on the device, mitigating the need for whitebox cryptography.
Before any secret is provided, however, Approov performs a deep inspection of your mobile app and the device it is running upon, and only if various integrity checks are passed are the secrets passed to it at runtime. This ensures that sensitive API secrets are not being continuously stored or delivered to unsafe places, such as fake apps or into malicious hands. Outgoing requests that may contain the secrets are pinned, ensuring they cannot be extracted by a Man-in-the-Middle (MitM) attack. Secrets can be rotated easily as needed, without the need to update the app. This eliminates the risk of secret exposure damaging your business.
“Secure networking is a critical aspect of mobile app security, particularly for apps that communicate over the network. In order to ensure the confidentiality and integrity of data in transit, developers typically rely on encryption and authentication of the remote endpoint, such as through the use of TLS. However, there are numerous ways in which a developer may accidentally disable the platform secure defaults or bypass them entirely by utilizing low-level APIs or third-party libraries.
This category is designed to ensure that the mobile app sets up secure connections under any circumstances. Specifically, it focuses on verifying that the app establishes a secure, encrypted channel for network communication. Additionally, this category covers situations where a developer may choose to trust only specific Certificate Authorities (CAs), which is commonly referred to as certificate pinning or public key pinning”
Approov implements dynamic certificate pinning. It can also maintain a list of the known valid roots through the Managed Trust Roots capability, which are kept inside the app alongside the device trust store. Alternatively, pins can be provided for each API domain, that are checked against the actual certificates presented, to secure the connection against Man-in-the-Middle attempts. All these may be dynamically updated using a secure over-the-air update mechanism allowing pins to be changed without any need to issue a new app version.
“Defense-in-depth measures such as code obfuscation, anti-debugging, anti-tampering, etc. are important to increase app resilience against reverse engineering and specific client-side attacks. They add multiple layers of security controls to the app, making it more difficult for attackers to successfully reverse engineer and extract valuable intellectual property or sensitive data from it, which could result in:
The controls in this category aim to ensure that the app is running on a trusted platform, prevent tampering at runtime and ensure the integrity of the app’s intended functionality. Additionally, the controls impede comprehension by making it difficult to figure out how the app works using static analysis and preventing dynamic analysis and instrumentation that could allow an attacker to modify the code at runtime. However, note that the lack of any of these measures does not necessarily cause vulnerabilities - instead, they add threat-specific additional protection to apps which must also fulfill the rest of the OWASP MASVS security controls according to their specific threat models.”
It's worth breaking this down for each of the four RESILIENCE controls outlined by the MASVS.
This control is aimed at ensuring the mobile platform (Android, iOS etc.) have not been compromised in a way that gives an advantage when performing reverse engineering. This requirement includes a focus on root/jailbreak detection, virtual environment detection, as well as device attestation in order to guarantee the authenticity of the user device.
Various root and jailbreak detection approaches are integrated into the Approov SDK. This can be configured so the app can report the detection, as well as ensuring the app does not receive valid Approov tokens or runtime secrets. A range of debug detection approaches are also integrated into the Approov SDK, covering low level and high level debug attachments. Again, detections can be reported immediately but this is strengthened since an app under debug cannot receive valid Approov tokens or runtime secrets. Debug detection is repeated on each API call that causes an Approov token to be fetched.
Approov has a range of specific detections for common instrumentation frameworks, such as Frida. Mechanisms are also in place to detect late attachment after the app has started. Further countermeasures are in place to detect the presence of hooking on key methods that might otherwise be used to prevent the detection of instrumentation frameworks.
Finally various checks are in place for both Android and iOS to determine if execution is on an emulator or simulator. On iOS, specific detection is made for apps running on an arm64 based Mac. Again, a direct response can be made in the app but crucially such an app never receives valid Approov tokens or runtime secrets.
This control is focused on checks which verify the integrity of the application, ensuring it has not been modified or repackaged. It can also focus on guaranteeing the runtime integrity of the application and the resources it depends on.
Approov captures signatures of valid apps and checks that the correct code is present at runtime. Tampering attempts are detected and prevent the app receiving valid Approov tokens or runtime secrets.
Approov analyzes the runtime memory space of the app sandbox and compares this to the expected layout. Mismatches are reported to the Approov cloud, allowing direct reporting and ensuring such an app does not receive valid Approov tokens or runtime secrets.
While it is impossible to completely prevent someone from analyzing your application using static analysis tools, obfuscation techniques can still play a role in increasing the difficulty of performing static analysis and this control reflects this. Layers of obfuscation techniques and steps to prevent leaking metadata about your application can help make your application more resistant to static analysis and somewhat discourage attackers.
Approov does not directly encrypt the code of the application. Approov uses a more robust approach, where the app code is measured by the Approov registration process and then verified at runtime by the Approov SDK. Thus any tampering of the application is detected and this causes the app to fail attestation, so that no valid Approov tokens are sent to it and it cannot obtain runtime secrets. This measurement process is not dependent on any secrets embedded in the app code itself.
The Approov SDK is responsible for performing the measurements and detections across the app’s runtime state. This allows the developer to be more selective in the obfuscation levels applied to the rest of the app, depending on whether the app code is of high value in itself. The Approov measurements ensure that requests to APIs cannot be spoofed as if they are coming from the real app.
The Approov SDK is of course protected itself, and Approov employs several innovative approaches to the measurement process, benefitting from the architectural differences it has from traditional app hardening approaches. Much of the functionality can be hidden from any attacker, since a substantial amount of the analysis can be performed server side using measurements collected from the client.
All key Approov measurements and detections are performed within the Approov SDK core, much of it implemented in native code. This is all heavily defended using symbol remapping and control flow obfuscation. Strings used for the detections are only provided at runtime and remain obfuscated in memory once loaded dynamically from the Approov cloud service.
Dynamic analysis is a technique used to observe or manipulate an application and its behavior at runtime. In order to prevent dynamic analysis it is important to build a defense-in-depth approach in order to protect against debuggers, as well as dynamic analysis tools and techniques. These detections should be carefully implemented and hardened to ensure they are not easily bypassed or observed by an attacker.
As previously described, Approov employs a diverse set of approaches to ensure resilience. These differ significantly from competitive approaches because of the unique partition between the data gathering of the Approov SDK and decision making of the Approov cloud. This completely divorces the failure response in the app from the point of the detection. Moreover, the measurement logic in the app itself is split between the runtime virtual machine instructions and the obfuscated native code implementation, making it extremely challenging to reverse engineer.
The Approov approach of partitioning the measurement in the SDK and the analysis in the Approov cloud takes the separation of detection and response even further, since the relationship between the two is secured inside the Approov cloud component and not part of the running code in the app that could be analyzed by an attacker.
In summary, App teams should integrate MASVS into their entire development lifecycle, from initial design through development, testing, and maintenance.
The MASVS tools and documents provide a comprehensive guide for implementing and verifying security in mobile applications throughout the lifecycle, and can be used:
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. This whitepaper lays out how Approov implements MASVS, providing comprehensive protection.
- VP Marketing, Approov
George is based in the Bay Area and has an extensive background in cyber-security, cloud services and communications software. Before joining Approov he held leadership positions in Imperva, Citrix, Juniper Networks and HP.
