One of the most well-known checklists for mobile app security is found in the OWASP Mobile Application Security Verification Standard (MASVS). If you implement the OWASP Mobile App Security Checklist thoroughly and meet all the requirements, your mobile app will have a good security foundation.
However, there are still some potential security gaps to consider. First, the app itself is responsible for conducting security checks and making decisions about its own security, which could allow an attacker to use an instrumentation framework to bypass or modify these checks and decisions. Second, the API backend is not necessarily restricted to serving requests solely from genuine, unmodified instances of the mobile app that are not under attack or running on a compromised device and environment.
This article will discuss how Approov can help you address both of these security gaps, while simultaneously enabling you to use Approov to comply with the OWASP Mobile Application Security Verification Standards.
Source: github:owasp-masvs
The Mobile Application Security Verification Standard (MASVS), which is intended to be used when the application is ready to be released, provides a security checklist as the baseline for the pentesting activities. On the other hand the OWASP Mobile Security Testing Guide (MASTG), describes how to verify each security requirement laid out in the MASVS.
The MASVS defines two security verification levels (MASVS-L1 and MASVS-L2), as well as a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 contains generic security requirements that are recommended for all mobile apps, while MASVS-L2 should be applied to mobile apps handling highly sensitive data. MASVS-R covers additional protective controls that can be applied if preventing sophisticated client-side threats is a design goal.
Fulfilling the requirements in MASVS-L1 results in a mobile app that follows the entry level security best practices and doesn't suffer from common vulnerabilities. MASVS-L2 adds additional defense-in-depth controls such as SSL/TLS pinning, resulting in a mobile app that uses more advanced security best practices which makes it resilient against more sophisticated attacks - assuming the security controls of the mobile operating system are intact and the end user is not viewed as a potential adversary. Fulfilling all, or subsets of, the software protection requirements in MASVS-R helps impede specific client-side threats where the end user is malicious and/or the mobile OS is compromised.
The first security gap stems from the fact that the OWASP resilience requirements suggest that mobile apps should respond to specific threats by alerting the user and/or terminating the mobile app. However, relying solely on this approach makes the mobile app vulnerable to attacks. Attackers can bypass the detection code by modifying the mobile app's behavior or short-circuiting the reporting process. This limitation should be taken into account when using open source SDKs for mobile app resilience checking that do in-app decisions about the mobile and device integrity.
To address the second security gap the API backend needs to be locked down to only serve requests from genuine and unmodified instances of the mobile app, that aren’t under any type of attack, and running in a trusted device.
Approov closes both security gaps with one solution. Approov’s Remote Mobile App Attestation doesn’t require in-app decisions and at the same time allows you to lock down the API server to the mobile app.
.jpg?width=927&height=399&name=Approov%20Architecture%20(no%20background).jpg)
The Approov approach is to only use the SDK to perform measurements and checks (2), while leaving the threat analysis and decisions about the device and mobile app integrity to the Approov cloud service (3), thus not making in-app decisions allows Approov to prevent attackers from knowing how it decides if the mobile app and its environment is trustworthy or not, which effectively closes the first security gap.
Closing the second security gap is achieved by implementing the Approov JWT token check in the API backend (5). When the mobile app uses the Approov SDK it receives an Approov token to signal to the API backend the result of the remote mobile app attestation performed by the Approov cloud service. This Approov token is added to each API request being sent (4 - option 2)), thus the API backend can use it as an authentication mechanism to lock down the API with the mobile app.
To prevent spoofing of the Approov measurement algorithm and/or to prevent it from being executed in a different environment, without detection, various low level and advanced techniques are employed in the Approov SDK, that goes from highly hardened native code, self measurements, minimal reliance in external libraries, minimal memory state resilience, runtime address integration, etc.. You can read more about all these low level techniques in detail on the whitepaper Achieving OWASP App Resilience with Approov.
Now that you understand how Approov works as one single solution to deliver Mobile App Security and API Security, you are better positioned to understand how Approov can help you with OWASP MASVS and in which points can be addressed from the OWASP security checklist.
The MASVS-L2 requires that a threat model exists for the mobile app and their APIs, where potential attack vectors have been identified alongside the countermeasures for them, and that the mobile app architecture and design takes security into consideration by implementing the adequate controls from the security checklist.
Approov helps you to cover some of these security checklist points, such as:
2.1 (MSTG-STORAGE-1) , 2.2 (MSTG-STORAGE-2) and 2.14 (MSTG-STORAGE-14) - The App Instance Secure Strings feature from Approov can be used to store at runtime sensitive data encrypted, like PII or Authentication tokens. The decryption key used to encrypt sensitive data on the device is only provided by the Approov cloud service to valid instances of the mobile app that pass the Approov remote mobile app attestation.
2.13 (MSTG-STORAGE-13) - For secrets usually hardcoded in mobile apps, like API keys, the Approov Runtime Secrets feature can be used to securely retrieve them from the Approov cloud service just-in-time of being used to perform the API request, which prevents them from being extracted from the mobile app binary in reverse engineer attacks. This offers a stronger defense by only delivering API access credentials to uncompromised instances of the mobile app. This can't be bypassed by attackers with reverse engineering techniques because secrets are delivered at runtime and secured by the Approov Remote Mobile App Attestation, which thwarts attempts to use instrumentation frameworks to attack the mobile app runtime.
While using Approov Runtime Secrets or App Instance Secure Strings you also have the peace of mind that Approov is compliant with the security checklist points from 3.1 (MSTG-CRYPTO-1) to 3.5 (MSTG-CRYPTO-5).
Here we will address OWASP MASVS-AUTH: Authentication and Authorization, that focus on ensuring that the mobile app implements authentication and authorization mechanisms securely, and we will see how Apoproov can be used to enhance the security of such implementations.
When authenticating a mobile app user on the API backend it’s important to know that such a request indeed originated from a genuine instance of the mobile app, not from other origins. However some mobile apps may not have a remote endpoint for authentication and may rely solely on local authentication, thus it’s important to ensure that a mobile app is running in a secure device and isn't under a runtime attack when performing user authentication locally.
When a mobile app doesn’t rely on an API backend everything needs to be done locally, including authentication, thus it’s important to ensure that the mobile app and device is trustworthy at all times, otherwise the authentication and subsequent authorizations will be compromised. To ensure trustworthiness and keep authorization tokens and the mobile app data secure at all times, Approov can be used to provide continuous remote mobile app attestation and encrypted storage of the tokens and data, where the decryption key is kept outside the device, in the Approov cloud service, and only provided to mobile apps that pass the attestation.
A correctly signed and not expired Approov token signals to the API backend that it can trust in the API request as coming from a genuine and unmodified instance of the mobile app, that isn’t under any type of attack, while an incorrectly signed one signals that the Approov cloud service deemed the mobile app and/or device integrity not trustworthy, therefore the API request must not be fulfilled by the API backend. The absence of the Approov token in the header of an API request is a clear indicator that the request isn’t even coming through the mobile app, therefore should also be rejected.
In addition to all these capabilities the Approov token can be bound with a user authentication token to create a unique binding between the user and a specific mobile app instance running in a specific device. You can read more about it in the Approov token binding docs.
With this in mind let’s see the following security checklist points:
4.1 (MSTG-AUTH-1) - Requires user authentication in each API endpoint. The endpoint to authenticate the user can be secured by Authenticating first the API request, thus ensuring that the user authentication request can be trusted.
4.3 (MSTG-AUTH-3) - The Approov token is signed with a secure algorithm.
4.6 (MSTG-AUTH-6) - Credential stuffing attacks are stopped by the Approov token check without reaching the user authentication check, because the attacker cannot provide a correctly signed Approov token. So, even if you don’t have the security mechanism to protect against an excessive number of attempts to authenticate you are protected by Approov.
4.10 (MSTG-AUTH-10) - We strongly recommend that all API endpoints should be secured with an Approov token check, not only the ones for sensitive transactions, therefore even if you don’t require user authentication you get the peace of mind to go ahead with the sensitive transaction knowing that its originated from a genuine and unmodified instance of your mobile app.
4.12 (MSTG-AUTH-12) - The Approov token can be considered an Authorization model and we strongly recommend it to run as soon as possible in the API request life-cycle, before any other form of authentication, because if you cannot trust the request then you should refuse it as soon as possible.
To achieve OWASP MASVS-L2 certification, mobile apps must have additional defense in depth measures to guarantee that only the intended communication channel is being used by the mobile app when talking with the API backend, like TLS pinning or their own certificate store. Approov provides both capabilities. Approov can maintain a list of known valid roots through its Managed Trust Roots feature, which are stored in the app alongside the device trust store. Alternatively, pins can be provided for each API domain and checked against the actual certificates presented to secure the connection against man-in-the-middle (MitM) attack attempts. These can be dynamically updated using a secure over-the-air update mechanism, allowing pins to be changed without requiring a new version of the mobile app:
Any API request on your mobile app needs to use the HTTP enhanced stack provided by Approov to benefit from dynamic certificate pinning or managed trust roots, but rest assured that this API requests are not proxied through the Approov cloud service, they are made directly from your mobile app to your API backend, but secured with Approov.
With this in mind let’s see the following security list checkpoints:
5.1 (MSTG-NETWORK-1) - The Approov SDK only allows the use of HTTPS, therefore if you make all your API requests through it then you are using a secure channel consistently through your mobile app, and one that uses dynamic certificate pinning.
5.2 (MSTG-NETWORK-2) - The Approov SDK only supports TLS as per current best practices, and doesn’t run on OS versions that don’t support it.
5.3 (MSTG-NETWORK-3) - When using the Approov Managed Trust Roots feature you are compliant with this point.
5.4 (MSTG-NETWORK-4) - Certificate pinning is hard when pins get hard coded in the mobile app, but Approov makes this easy with Dynamic Certificate Pinning. The alternative is to use a backed-in trust store via Approov Managed Trust Roots feature.
5.6 (MSTG-NETWORK-6) - When using the Approov SDK to make all your API requests then you have the peace of mind that you are using secure and up-to-date libraries for your HTTP stack.
This section describes the MASVS-R resilience requirements and which points in the checklist does Approov provide the corresponding protections.
The OWASP MASVS-R resilience requirements are split as:
Impede Dynamic Analysis and Tampering
Device Binding
Impede Comprehension
Impede Eavesdropping
Approov helps you to cover the security checklist points:
From 8.1 (MSTG-RESILIENCE-1) to 8.9 (MSTG-RESILIENCE-9) inclusive - Approov covers all these items through its device and mobile app integrity checks, which we call Remote Mobile App Attestation. The Approov SDK on the device only executes challenges and sends the results to the Approov cloud service, which then makes a quick and deterministic decision about the security of the mobile app and device. This eliminates false positives and false negatives, giving a simple Yes or No response. You can control how the decision is made through the Appoov security policies.
This is solely about checklist point:
8.10 (MSTG-RESILIENCE-10) - Approov uses privacy-compliant device IDs to achieve device binding. This ID is provided as a claim in the Approov JWT token issued by the Approov cloud service. The token indicates to the API backend whether the mobile app has passed the attestation or not. Optionally, the token can also be bound with a hash of the Authorization token for the user of the mobile app, providing anonymous binding of the user with their device. Approov can also gather other device characteristics for later analysis if a particular device is suspected of being used to perform an attack on the mobile app. The device also holds a persisted state, which is encrypted server-side, and is verified against the collected state to detect attempts at cloning a particular device state.
These cover the checklist points:
8.11 (MSTG-RESILIENCE-11) - Approov does not directly encrypt the mobile app code. Instead, the code is measured by Approov during two different stages. Firstly, when the mobile app binary is registered with the Approov CLI before being released. Secondly, at runtime, the Approov SDK measures the code again. If any tampering is detected during runtime, the mobile app will fail the remote mobile app attestation performed by the Approov Cloud service. This measurement process is not dependent on any secrets embedded in the mobile app code.
8.12 (MSTG-RESILIENCE-12) - By using low level code hardening techniques, the Approov SDK is designed to protect the core functionality of the SDK itself, which is responsible for measuring and detecting the runtime state of the mobile app. These measurements and detections are then used by the Approov cloud service to perform remote mobile app attestation. This approach means that much of the functionality present in traditional RASP solutions, which rely on decisions being made on the device itself, can be hidden from attackers since a significant amount of the analysis is performed on the Approov cloud service side using measurements collected from the mobile app device.
These cover the checklist point:
Approov provides a simple way to comply with the above referenced security checklist points from OWASP MASVS by adding an effective MASVS-L2 and MASVS-R resilience layer for them to your mobile app via a comprehensive set of environmental measurements and detections deployed in a hardened SDK that delegates the threat analysis and decisions about the device and mobile app integrity to the Approov cloud service.
The Approov remote app mobile app attestation capabilities avoids the vulnerabilities associated with resilience checking approaches implemented in isolation within the mobile app alone, aka in-app decisions, as usually seen in solutions addressing OWASP MASVS-L2 and MASVS-R.
In addition to a very flexible Approov dynamic certificate pinning implementation, that allows for secure over-the-air updates of the pins, Approov also provides Runtime Secrets to allow for just-in-time secure delivery of the API key required to make the API request, but only to mobile apps that pass the remote mobile app attestation.
Keeping up with the latest threats is a continuous and very laborious process. Using Approov allows this to be outsourced, freeing the mobile app developers to focus on features and to secure the implementation of the mobile app code itself, the MASVS-L1, and some MASVS-L2.
Cover Photo by Markus Winkler on Unsplash
Paulo Renato is known more often than not as paranoid about security. He strongly believes that all software should be secure by default. He thinks security should be always opt-out instead of opt-in and be treated as a first class citizen in the software development cycle, instead of an after thought when the product is about to be finished or released.
