Thursday, 28 July, 2022 UTC


Summary

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.
This kind of protection is especially important for hybrid mobile apps since the application packages will normally contain a JavaScript bundle file, containing the app’s logic. It is important to note that these applications are stored in the end user's device.
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.
This client-side JavaScript can easily be targeted, as anyone can debug this code and even modify it. Companies’ proprietary algorithms and logic end up running in an adversarial environment, which opens the door to a series of attacks, including automated abuse, piracy, intellectual property theft, and data exfiltration.
This highlights the importance of adding a security layer to reduce the app’s attack surface. OWASP recommends adopting the R level together with L1 or L2. In the table below, we show you how each requirement of MASVS-R can be addressed by Jscrambler, both at the app's JavaScript layer and in its native 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.5 The app detects, and responds to, being run in an emulator. Jscrambler’s Code Hardening feature provides anti-emulator capabilities, detecting if the source code is being executed by e.g. Facebook's (Meta) prepack custom JavaScript engine.
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.11 All executable files and libraries belonging to the app are either encrypted on the file level and/or important code and data segments inside the executables are encrypted or packed. Trivial static analysis does not reveal important code or data. While Jscrambler obfuscates JavaScript source code, it can also encrypt native code through dedicated 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.
This information is important to retain, not only for reasons of compliance but also to ensure your apps are completely protected against client-side threats. If you are building mobile apps with JavaScript, you should secure your source code against theft and reverse-engineering. Start a free Jscrambler trial and protect your code in 2 minutes!