MAS-R - Resilient Security
How to proceed when no MASTG TEST exists
The MASTG does not yet provide dedicated tests for every MASWE. Defining a weakness and defining a reliable, reproducible way to test for it are different tasks, and some areas require extensive research, validation, or refinement before they can be captured as formal MASTG TESTs. The guide also evolves continuously as platforms, frameworks, and testing techniques change.
Even when no dedicated MASTG TEST exists, you can still assess the weakness.
-
Start with the MASWE: Review its "Modes of Introduction" to understand the concrete conditions that may introduce the weakness and what should be tested.
-
Check related MASTG content: Look at similar or related existing MASTG TESTs, as they can provide useful testing patterns, structure, and inspiration for designing a new test. Also consult relevant MASTG KNOW, TECH, and TOOL entries, together with the official mobile platform documentation, to understand the topic and identify suitable testing techniques.
-
Contribute back: If you develop a reliable testing procedure, consider contributing a new MASTG TEST and a MASTG DEMO so others can reuse it.
MAS-R tries to prevent an attacker from extracting intellectual property, bypassing security controls (e.g., license checks, DRM, authentication) or negatively impacting the ecosystem (e.g. cheating at a game, unlocking paid features for free, …). It incorporates a range of security measures aimed at enhancing resilience against reverse engineering and tampering (client-side) threats, such as repackaging or extraction of sensitive data, IP theft (e.g., proprietary algorithms), piracy.
It assumes that:
- the security controls of the mobile operating system cannot be trusted (e.g. the device is rooted/jailbroken).
- the primary user of the device is viewed as an adversary (e.g. a reverse engineer or cheater).
- other applications installed on the device are viewed as an adversary.
- a third party with or without physical access is viewed as an adversary.
MAS-R is recommended for
- apps that have a strong need to safeguard their own business assets and logic.
For example, in the gaming industry, competitive online games have a strong need to prevent modding and cheating: a large population of cheaters will have a negative impact on the gaming experience and scare away the legitimate player base. MAS-R's anti-tampering controls raise the effort required to cheat, even though they cannot eliminate it entirely.
Note that the absence of any MAS-R measures does not inherently introduce vulnerabilities. Rather, these measures offer additional, threat-specific protection to applications. However, this is provided that these apps also meet the rest of the OWASP MASVS security controls appropriate to their specific threat models. Crucially, MAS-R is meant to augment and not replace MAS-L1 and MAS-L2. It should not be used standalone but as an extra layer of defense, supplementing the base security controls in a defense-in-depth strategy.
Note that these measures cannot assure a 100% effectiveness, as the reverse engineer will always have full access to the device and will therefore end up succeeding given enough time and resources.
Requirements¶
| Requirement | MASWE ID | Platform | MASVS ID | Tests | Status |
|---|---|---|---|---|---|
| The app detects if it runs on a rooted/jailbroken device and reacts appropriately. | MASWE-0051: Root/Jailbreak Detection Not Implemented | MASVS-RESILIENCE-1 | 4 | ||
| The app detects when it is running inside an app-virtualization environment. | MASWE-0052: App Virtualization Environment Detection Not Implemented | MASVS-RESILIENCE-1 | 0 | ||
| The app detects when it is running in an emulated or virtual device environment. | MASWE-0053: Emulated or Virtual Device Detection Not Implemented | MASVS-RESILIENCE-1 | 2 | ||
| The app implements device attestation. | MASWE-0054: Device Attestation Not Implemented | MASVS-RESILIENCE-1 | 0 | ||
| The app detects attacks by malware. | MASWE-0055: Malware Detection Not Implemented | MASVS-RESILIENCE-2 | 0 | ||
| The app implements app attestation. | MASWE-0056: App Attestation Not Implemented | MASVS-RESILIENCE-2 | 3 | ||
| The app verifies the integrity of its resources. | MASWE-0057: App Resources Integrity Not Verified | MASVS-RESILIENCE-2 | 2 | ||
| The app detects unauthorized changes to its code and execution flow at runtime. | MASWE-0058: Runtime Code Integrity Not Verified | MASVS-RESILIENCE-2 | 2 | ||
| The app implements code obfuscation. | MASWE-0059: Code Obfuscation Not Implemented | MASVS-RESILIENCE-3 | 3 | ||
| The app applies resource obfuscation to hinder reverse engineering. | MASWE-0060: Resource Obfuscation Not Implemented | MASVS-RESILIENCE-3 | 0 | ||
| The app does not contain debug artifacts. | MASWE-0061: Debug Artifacts Not Removed | MASVS-RESILIENCE-3 | 7 | ||
| The app applies application-level payload encryption in addition to transport-layer encryption. | MASWE-0062: No Application-Level Payload Encryption | MASVS-RESILIENCE-3 | 0 | ||
| The app disables debug mechanisms. | MASWE-0063: Debug Mechanisms Not Disabled | MASVS-RESILIENCE-4 | 3 | ||
| The app detects debugger attachment at runtime and responds to protect sensitive operations. | MASWE-0064: Debugger Detection Not Implemented | MASVS-RESILIENCE-4 | 4 | ||
| The app detects dynamic analysis tools and responds to protect sensitive operations. | MASWE-0065: Dynamic Analysis Tools Detection Not Implemented | MASVS-RESILIENCE-4 | 0 |