Blog

Mobile Application Testing Strategy: How to Take The Security of Your Mobile Apps to the Next Level of OWASP

What is OWASP and why is it becoming increasingly relevant in the IT industry? What methods exist to complete validations according to its security standards? Take a look at this article from Matías Reina and take its input in mind for your mobile application testing strategy. And don’t forget! You can connect with Apptim for immersing yourself efficiently in the OWASP universe and mobile security.

Recently, we published an article in which we contextualized and briefly explained why it is so important to focus on mobile security as part of your mobile application testing strategy when developing quality applications. 

It is essential to remember that all or the vast majority of apps use a backend of services that must be tested according to the Open Web Application Security Project (OWASP) standards. And it is not possible to perform an evaluation of the mobile part without considering the backend.

Why is OWASP so crucial on this path? It is a benchmark organization and community in web and now also mobile security. It proposes an open source and collaborative methodology for security audits to ensure regular review of a project to minimize errors and risks.

How Does OWASP Work Concerning Mobile and Why it is so Important for Your Mobile Application Testing Strategy?

In mobile, we have OWASP MAS (Mobile Application Security), which centralizes the area’s initiatives. Within OWASP MÁS, we have:

✅ MASVS – Mobile Application Security Verification Standard (MASVS)

Currently, at version 1.4.2, MASVS establishes the security requirements for an app, which can be useful in different scenarios:

  1. As a metric – To provide a security standard against which existing mobile apps can be compared by developers and application owners.
  2. As guidance – To provide guidance during all phases of mobile app development and testing.
  3. During procurement – To provide a baseline for mobile app security verification.

MASVS has a set of requirements for each of the following aspects of the app:

  • V1: Architecture, Design, and Threat Modeling Requirements.
  • V2: Data Storage and Privacy Requirements.
  • V3: Cryptography Requirements.
  • V4: Authentication and Session Management Requirements.
  • V5: Network Communication Requirements.
  • V6: Environmental Interaction Requirements.
  • V7: Code Quality and Build Setting Requirements.
  • V8: Resiliency Against Reverse Engineering Requirements.

✅ MASTG – Testing Guidelines: Mobile Application Security Testing Guide 

They are currently at version 1.5. The MASTG is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the controls listed in the MASVS. There are two types of approaches to test each requirement, which complement each other:

  1. SAST – Static Application Security Testing: involves analyzing the code, and the artifacts that make up my system.
  2. DAST – Dynamic Application Security Testing: involves running the application to analyze its behavior.

✅ OWASP MAS Checklist

It is a spreadsheet that integrates the corresponding MASTG tests on each platform (Android and iOS) for each MASVS requirement.

Mobile AppSec Model For Your Mobile Application Testing Strategy

What security levels exist for the aspects mentioned above? We can list 2: L1 and L2. L1 is the basic one, which any mobile app should have. L2 adds some extra requirements for those applications where security is more relevant because they handle sensitive data. 

In addition, they can be combined with another set of requirements related to MASVS-R reverse engineering resilience, which aims to protect the intellectual property of applications and make it more difficult for hackers to analyze them. The R level should never be understood as a replacement for security controls.

Reverse engineering resiliency requirements can be combined with the two security levels, so we have 4 possible options to choose from for our application:

  • L1
  • L1+R
  • L2
  • L2+R

As we start our analysis on what level of security we need according to our business, we can choose one of those 4 levels or a subset of our own that combines the requirements of L1, L2, and R.

MASA

Mobile Application Security Testing Assessment (MASA)

Based on these standards, the “Mobile Application Security Assessment” (MASA) is created with the support of Google, which collects a subset of the requirements of the MASVS-L1 level. This subset adds a new level to the 4 previously described. It is a lower security level and can be a good initial target when starting to evaluate the security aspects of applications. 

MASA allows you to add a highlight in the Play Store, which indicates that the application has an external security review. As we mentioned at the beginning of the article, this gives users more confidence in the security of apps that have such a highlight.

Ultimately, as specified by the App Defense Alliance, performing regular security testing
as part of your mobile application testing strategy can help you identify key vulnerabilities and mitigate future liability. OWASP MASVS can be applied to any mobile app.
For example, in a variety of app categories, such as IoT, fitness/health, social, communications, VPN, productivity, and many more.

“The scope of the assessment consists of client security, authentication to the backend or cloud service, and connectivity to the backend or cloud service in which overall security and some privacy best practices are analyzed, ” the official site points out. “The assessment will review a subset of level 1 MASVS requirements that can be tested and are available on GitHub here.”

Security Testing Automation

What are the validations being performed, and are they automated? 

While OWASP is making a great effort to make the various MASVS requirements clear and automatable, it is not currently possible to automate all requirements. This does not imply that tools for static code analysis or other tools are not used to increase the efficiency of analysis when necessary. But each application is different and may require custom analysis to see how the requirements and guidelines fit it.

Can a functional tester do security testing?

Many of the OWASP requirements and guidelines require a great deal of business knowledge that the tester can use to assist or check some of the MASVS requirements. Some will require assistance on technical issues to be able to take evidence, such as application logs and SQLs it runs, among others.

Do you know the new version of MASVS? Carlos Holguera and Sven Schleier are leading a refactor to achieve version 2.0, and there will also be a refactoring of the MSTG to ensure that each MASVS control has a clearly defined test case.

We share some images to let you know more about what’s coming:

Refactoring: Things to keep in minds while refactoring

Keep Abstraction- Leave details for the MSTG.

Simplify- Less requirements, better categorized.

Narrow Scope- Rely more on other standards (e.g. OWASP ASVS, OWASP SAMM.)

Ensure Actionability- Test cases in the MSTG more automation friendly. 

Clarity- Leave  no room for ambiguity in language and formulation. 

Attackers View- Clear overview of the mobile attack surface.

Are you using MASVS as a standard to develop secure applications or are you planning to do so? We invite you to do it through a quality partner like Apptim, a spin-off company of Abstracta. It is a company that offers solutions for creating robust mobile applications, used by more than 250 companies worldwide. 

Apptim helps you to get involved in the OWASP universe quickly and efficiently. Schedule a free call in one click!

In need of a testing partner for applying all this in your mobile application testing strategy? Abstracta is one of the most trusted companies in software quality engineering. Learn more about our solutions, and contact us to discuss how we can help you grow your business.

Follow us on Linkedin & Twitter to be part of our community!

338 / 457

Leave a Reply

Required fields are marked