Verifying Mobile App Security Using the OWASP Checklist
Even though modern mobile operating systems like iOS and Android are arguably more secure by design compared to traditional Desktop operating systems, there's still a lot of things that can go wrong when security is not considered during the mobile app development process. Data storage, inter-app communication, proper usage of cryptographic APIs and secure network communication are only some of the aspects that require careful consideration. The OWASP Mobile Security Testing Project aims to provide developers and security testers with highly practical requirements, process and tools to develop secure mobile apps.
The project develops three documents that can be used to plan and verify security controls during any phase of mobile app development, as well as during pre-release code review and penetration testing:
- The Mobile Application Security Verification Standard (MASVS): This standard document defines a mobile app security model and lists generic security requirements for mobile apps. It can be used by architects, developers, testers, security professionals, and consumers to define what a secure mobile application is.
- The Mobile Security Testing Guide (MSTG): The MSTG is a manual for testing the security of mobile apps. It provides verification instructions for the requirements in the MASVS along with operating-system-specific best practices (currently for Android and iOS). The MSTG helps ensure completeness and consistency of mobile app security test. It is also useful as a standalone learning resource and reference guide for mobile application security testers.
- Mobile App Security Checklist: A checklist for tracking compliance against the MASVS during practical assessments. The list conveniently links to the MSTG test case for each requirement, making mobile penetration app testing a breeze.
It is important to note that the security standard, testing guide and checklist are closely related: They all map to the same basic set of requirements. Depending on the context, the documents can be used stand-alone or in combination to achieve different objectives.
Figure 1: Security requirements link to test cases (how-tos). The checklist provides an overview and links to both the security requirements and test cases.
For example, the MASVS requirements may be used in the planning and architecture design stages, while the checklist and testing guide may serve as a baseline for manual security testing or as a template for automated security tests.
In this blog post, we'll show how to use the checklist to ensure completeness during a mobile application security assessment.
First of all, you'll need to decide what security level to test against. The level of security needed is something that should ideally have been decided on early in the SDLC - but unfortunately we're not living in an ideal world! At the very least, it is a good idea to walk through the checklist with the client and make a reasonable selection of L2 controls to cover during the test - for example if the app handles highly sensitive data.
The controls in MASVS L1 are appropriate for all mobile apps - the rest depends on the threat model and risk assesment for the particular app. Discuss with the client what requirements are applicable and which ones are out of scope for testing, perhaps due to business decisions or company policies. Also consider whether some L2 requirements may be needed due to industry regulations or local laws - for example, in 2-factor-auth may be obligatory for a financial app.
If security requirements were already defined during the SDLC, even better! Ask for this information and document it on the front page of the Excel sheet ("dashboard"). More guidance on the verification levels and guidance on the certification can be found in the MASVS.
All involved parties need to agree on the decisions made and on the scope in the checklist, as this will present the basis for all security testing, regardless if done manually or automatically.
Mobile App Security Testing
During a manual test you can simply walk through the applicable requirements one-by-one - for a detailed testing how-to simply click on the link in the "Test procedures" column. These links lead to the respective chapter in the OWASP Mobile Security Testing Guide. Note however that work on the guide is still ongoing so some how-tos have not been written yet (ideally, if you discover missing content, you could contribute it yourself).
Figure 2: The checklist. Requirements marked with "L1" should always be verified. Choose either "pass" or "fail" in the "status" column. The links in the "testing procedure" column lead to the OWASP Mobile Security Testing Guide.
The status column can have three different values that need to be filled out:
- Pass: Requirement is applicable to mobile App and implemented according to best practices.
- Fail: Requirement is applicable to mobile App but not fulfilled.
- N/A: Requirement is not applicable to mobile App.
Reverse Engineering Resiliency Controls
Anti-reverse-engineering measures (MASVS-R) are listed in a separate tab. You don't have to bother with those unless the app has a particular need to prevent tampering and reverse engineering - we won't discuss this in detail in this article, but it will be covered in more detail in the testing guide and future articles.
The Management Summary
An awesome spider chart is generated on the fly according the results of the requirements for both supported platforms (Android and iOS) in the "Management Summary" tab. You can use this in your report to point out areas that need improvement, and visualize progress over time.
The spider chart visualizes the ratio of passed and failed requirements in each domain. As can be seen above all requirements in "V3: Cryptography Verificiation Requirements" were set to "pass", resulting in a value of 1.00. Requirements that are set to N/A are not included in this chart.
A more detailed overview can also be found in the "Mangement Summary" tab. This table gives an overview according to the eight domains and breaks down the requirements according to it's status (Passed, Failed or N/A). The percentage column is the ratio from passed to failed requirements and is the input for the spider chart described above.
The Mobile App Security Checklist was created by Abdessamad Temmar (Slack: @Temmar), Alexander Anthuk (Slack: @alex), and Sven Schleier (Slack: @sushi2k). Please reach out to us directly in the OWASP Mobile Testing Guide Slack channel for questions and feedback.