Mobile applications dominate digital traffic compared to web apps and accounted for nearly 143 billion downloads in 2022. As such, we need to treat mobile apps as a top priority and deliver high-quality user experiences.
Despite the world becoming increasingly mobile, mobile application security lags behind in the development process. All too often the rush to release innovative new features sacrifices security and allows issues to escape into the wild. Digital.ai knows that more than half of apps in production are under attack.
Over a 28-day period in October 2022, 55% of all the apps we monitored were either run in a debugger or were run with modified code. Attackers recognize that digital traffic has shifted to mobile, and they also know that many mobile apps lack proper security, with at least 85% of all mobile apps presenting one or more vulnerabilities that fail the OWASP Mobile Application Security Verification Standard (MASVS).
What Is the OWASP MASVS?
The Open Worldwide Application Security Project (OWASP) Mobile Application Security (MAS) Project aims to improve the security of mobile apps.The MASVS offers guidance and best practices for securing mobile applications OWASP MASVS focuses on seven specific domains: storage, cryptography, authentication, network communication, environmental interaction, code quality and resiliency against reverse engineering.
How Has the OWASP MASVS Evolved?
Before April 1, 2023, MASVS version 1.5 provided DevSecOps practitioners with three verification levels (L1, L2, and R) to examine four quadrants of application types when threat modeling. These levels have been reworked as “security testing profiles” and shifted to the OWASP MASTG to catalog security controls. These types included:
- MASVS-L1 – Standard Security: Consists of the best practices for secure coding, like code quality, handling sensitive data, and interaction with the mobile environment.
- Example: This level includes apps where lightweight Level 1 basic security would be sufficient, such as the WebMD app which has no regulatory requirements and is fairly simple with no authentication, login, or Personally Identifiable Information (PII).
- MASVS-L2 – Defense in Depth: This model has everything included in MASVS-L1 plus additional recommendations based on the threat model for industries such as banking and healthcare that handle particularly sensitive data.
- Example: This level includes apps that deal with regulated industry data like a standard health monitoring app that records a user’s weight, blood pressure, etc. These are apps that perform simple tasks but handle highly sensitive data and must have compliance considerations.
- MASVS-R – Resiliency Against Reverse Engineering and Tampering: Protection from specific client-side attacks, such as tampering, modding, or reverse engineering.
- Example: Apps that combine MASVS L1 and high RE Resilience include a drug formulary app. Although there is no PII in an app like this, tampering with the data can result in serious consequences like the creation of an altered drug. As such, this type of protection prioritizes IP protection and prevents malicious modification from threat actors.
- Example: Apps that combine MASVS L2 and high RE Resilience include apps that perform complex activities between users and handle highly sensitive data, such as a healthcare drug delivery system. In this scenario, compliance and IP protection are key, and preventing malware attacks is baked into your threat model.
On April 1, 2023, OWASP MAS released the MASVS version 2.0. The 2.0 version resembles a NIST standard and simplifies the language used to describe the requirements for making mobile apps secure. Version 2.0 of MASVS removes the L1, L2, and R categories found in version 1.5, shifting to a “back-to-basics” reliance on the seven categories mentioned above.
Managing the risks of the mobile threat landscape requires teamwork. The OWASP MASVS provides a road map for successful DevSecOps – Dan Shugrue, Security Product Marketing Manager for Digital.ai
The efficacy of these changes is of course open to interpretation. We believe that the new version makes it easier for product owners to see a relatively straight line from “not secure” (adheres to none of the seven domains) to most secure (adheres to all of the seven domains). Thus, product owners who want the most secure app possible can simply gate applications until they satisfy all seven domains, as opposed to learning which of the seven make “L1”, which make “L2”, which make “R” and which of the three categories their apps should adhere to.
Use OWASP MASVS to Strengthen Mobile AppSec
To cover most of the first five domains, readers can refer to the excellent post from NowSecure. But for now, let’s delve into two domains in particular, Cryptography and Resilience.
Due to the highly portable nature of mobile devices, they can often be lost or stolen. Threat actors who gain physical access to a device can potentially access the sensitive data stored within. Cryptography protects data by encrypting it so that it cannot be easily read or accessed by an unauthorized user. The controls in this category are as follows:
- MASVS-CRYPTO-1: The app employs current strong cryptography and uses it according to industry best practices
- MASVS-CRYPTO-2: The app performs key management according to industry best practices
To cover the cryptographic requirements detailed in the MASVS, app owners can use a white-box cryptography solution. Why call out cryptography specifically? Because apps use encryption keys to encrypt and decrypt ingoing and outgoing traffic as well as data-at-rest within the app itself. If/when an app’s source code is reverse engineered, these keys are used by attackers to decipher encrypted information. Data resident within the app can then be exfiltrated, along with all communications with back-end office systems. White box cryptography combines mobile app code and keys together with cryptographic operations so that the keys are hidden and cannot be extracted from apps. If you want more information about Digital.ai’s white box cryptography solution, click here.
The resilience domain focuses on using defense-in-depth measures such as code obfuscation, anti-debugging and anti-tampering to increase app resilience against reverse engineering and attacks from threat actors. They add multiple layers of security controls to the app to ensure the mobile app runs on a trusted platform, prevent tampering at runtime and ensure the integrity of the app’s intended functionality. These security controls are as follows:
- MASVS-RESILIENCE-1: The app validates the integrity of the platform
- MASVS-RESILIENCE-2: The app implements anti-tampering mechanisms
- MASVS-RESILIENCE-3: The app implements anti-static analysis mechanisms
- MASVS-RESILIENCE-4: The app implements anti-dynamic analysis techniques
To cover the resilience domain, app owners must protect the “live” network connections to the backend systems that your mobile apps contain that are necessary to be useful. These actual network connections become “working examples” of how to bypass your perimeter defense systems. If weaknesses in the “working examples” are exposed, threat actors exploit them to conduct any manner of attacks such as application cloning, credential theft, cryptojacking, script injecting and keylogging.
Protecting those working examples from being reverse-engineered starts with obfuscating code and providing a means to detect when and if apps are being run in unsafe environments. How does one obfuscate code? By taking unprotected code and feeding it, along with the protection blueprint that you create into an engine that produces the protected code. The protected application contains obfuscated machine code that runs as originally designed but is virtually unreadable by threat actors — even after it has been fed into a disassembler.
Another important method of protecting applications is by adding anti-tampering techniques. In this instance, anti-tamper primarily refers to the ability to detect two conditions. First, when your app runs in an unsafe environment that might allow it to be tampered with. Classic examples of these types of environments are debuggers, emulators, and rooted/jailbroken devices. Second, when the code in your app has been modified. To look for that latter, you can add a guard such as a “Checksum” guard to determine if the app that is running is the same as the app you put into production. To learn more about how obfuscation methods and anti-tamper protections can be added on premises at build or by Digital.ai in the cloud, click here.
Digital.ai is all about application hardening – or in other words, obfuscating code, providing the ability for enterprises to monitor software once it’s outside of the firewall and to react to attacks by shutting down or deprecating functionality in apps under attack. Managing the risks of the mobile threat landscape requires teamwork. The OWASP MASVS provides a road map for successful DevSecOps, offering a comprehensive security standard with a clear set of guidelines for assessing and enhancing the security of mobile apps.
Better Together
Digital.ai application security helps you obfuscate your code, monitor your apps in the wild and react to attacks with Runtime Application Self Protection (RASP). These capabilities help you meet the resiliency requirements in the OWASP MASVS. NowSecure mobile application security testing ensures your mobile apps meet other OWASP MASVS requirements. Together, Digital.ai and NowSecure make the perfect team that will help you take home the gold and thwart threat actors.
Devs can learn more about how to improve the security of mobile apps with OWASP MAS by watching the NowSecure/Digital.ai webinar MASVS Team Up: Bulletproof Mobile Security from Dev Through Prod and the Digital.ai short informational video Build Secure Software.
