In this post, we will address the role of OWASP’s MASVS-R, the Mobile Application Security Verification Standard, the application standard for mobile applications security, and how we can address it with Jscrambler. This regulation helps developers increase the security of mobile apps, providing a list of requirements an application should adhere to.
Exploring OWASP MASVS-R
The MASVS being a standard, it provides a list of requirements that an application should adhere to. There are two security levels: MASVS-L and MASVS-R. The first one is divided into L1, which contains generic security requirements that are recommended for all apps, and L2, which contains requirements for defense-in-depth.
MASVS-R consists of a set of reverse engineering requirements that are useful for providing client-side defenses. This type leads us to address the issue of client-side security in more depth, defining how Jscrambler can help to adhere to each regulation defined by OWASP.
Even though the MASVS-R is a separate level for client-side attacks, that doesn’t mean that the L1 and L2 compliant apps can’t employ the R level as well. Tampering, debugging, and reverse engineering of the application’s source code, are some of the attacks covered by OWASP’s MASVS-R.
Addressing OWASP MAVS-R with Jscrambler
MASVS-R covers attacks such as tampering, debugging, and reverse engineering, that can be performed on the app’s source code.
|MASVS-R #||OWASP Description||How Jscrambler Addresses|
|8.1||The app detects, and responds to, the presence of a rooted or jailbroken device either by alerting the user or terminating the app.||Jscrambler’s Root/Jailbreak detection feature detects these risky devices and can both alert the user, terminate the app, or block certain app features.|
|8.2||The app prevents debugging and/or detects, and responds to, a debugger being attached. All available debugging protocols must be covered.||Jscrambler provides multiple anti-debugging features, including Self-Defending and Dead Objects, which actively prevent debugging at runtime, breaking the app when a debugger is opened.|
|8.3||The app detects, and responds to, tampering with executable files and critical data within its own sandbox.||Jscrambler’s Self-Defending and Self-Healing features prevent tampering attempts at runtime, both by breaking the app or only allowing the correct code to run.|
|8.4||The app detects, and responds to, the presence of widely used reverse engineering tools and frameworks on the device.||Jscrambler’s Code Hardening feature is built-in to every code protection and provides up-to-date protection against all reverse engineering tools.|
|8.6||The app detects, and responds to, tampering the code and data in its own memory space.||Jscrambler’s Self-Defending and Self-Healing features prevent tampering attempts at runtime. Jscrambler’s Memory Protection feature ciphers sensitive data using cryptographic algorithms, preventing values stored in memory from being accessed and tampered with at runtime.|
|8.7||The app implements multiple mechanisms in each defense category (8.1 to 8.6). Note that resiliency scales with the amount, diversity of the originality of the mechanisms used.||Under the hood, Jscrambler uses multiple defense mechanisms, including different ways to detect debugging/tampering attempts and to detect if the device is rooted/jailbroken.|
|8.8||The detection mechanisms trigger responses of different types, including delayed and stealthy responses.||Jscrambler combines different approaches to prevent tampering and debugging attempts, including customizable countermeasures and real-time security alerts.|
|8.9||Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis.||Jscrambler’s polymorphic obfuscation is applied to all anti-tampering and anti-debugging defenses, making it extremely hard for attackers to de-obfuscate the code both using static and dynamic analysis.|
|8.10||The app implements a 'device binding' functionality using a device fingerprint derived from multiple properties unique to the device.||Device binding can be obtained using Jscrambler’s integrations with native code protection technologies.|
|8.12||If the goal of obfuscation is to protect sensitive computations, an obfuscation scheme is used that is both appropriate for the particular task and robust against manual and automated de-obfuscation methods. The effectiveness of the obfuscation scheme must be verified through manual testing.||Jscrambler provides over 35 different transformations, along with polymorphic behavior to greatly improve the resiliency of the protected source code against manual and automated de-obfuscation. The effectiveness of the obfuscation can be analyzed by following this checklist.|
|8.13||As a defense in depth, next to having solid hardening of the communicating parties, application level payload encryption can be applied to further impede eavesdropping.||This level of encryption can be obtained using Jscrambler’s integrations with native code protection technologies.|