Implement Mobile Application Security
Learning Objectives
After completing this unit, you’ll be able to:
- Identify the Open Web Application Security Project’s mobile security resources.
- List actions to address improper platform usage.
- Describe how to mitigate insecure data storage, communication, and authentication.
- Explain the risk associated with insufficient cryptography.
Before You Start
If you completed the Mobile Application Security module, then you already know about the mobile application (app) landscape and key skills relevant to mobile application security (appsec) engineering. Now let’s talk about how to leverage the Open Web Application Security Project’s (OWASP’s) mobile security resources to help you address mobile security risks.
OWASP’s Mobile Security Resources
OWASP® is a nonprofit foundation that works to improve the security of applications (apps) and software by providing guidelines through local and global conferences and open source software projects. These include the OWASP Mobile Top 10 project, web app project, application programming interface (API) security project, serverless computing project, and much more. In this module, we use the OWASP Mobile Top 10 as a framework to explain the way to implement mobile appsec.
As a mobile application security (appsec) engineer, your challenge is to secure an ever-growing and constantly updating mobile app portfolio with finite resources. Thankfully, you can standardize and scale mobile appsec testing using the OWASP Mobile Security Project. The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile apps. You can use the OWASP’s mobile security resources to build efficient and effective mobile appsec programs. Let’s take a quick look at some of the OWASP’s mobile security resources.
OWASP Mobile Application Security Verification Standard
The OWASP Mobile Application Security Verification Standard (MASVS) is a standard for mobile appsec. As a mobile appsec engineer, you can use the MASVS to develop more secure apps, and to ensure completeness and consistency of security test results. The goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation. The MASVS maps directly to the OWASP Mobile Security Testing Guide (MSTG).
OWASP Mobile Security Testing Guide
The OWASP MSTG is a project that seeks to define the industry standard for mobile appsec. It covers the processes, techniques, and tools you can use during a mobile appsec test, and an exhaustive set of test cases that enables you to deliver consistent and complete test results. The OWASP MSTG is a comprehensive manual for mobile appsec testing and reverse engineering for iOS and Android mobile security testers.
OWASP Mobile Top 10
The OWASP Mobile Top 10 list is a great resource for mobile appsec engineers who want to design and secure mobile apps, because many of them are inherently vulnerable to security risks. The OWASP Mobile Top 10 is a mobile security project focused on highlighting security vulnerabilities in mobile apps and the remediation strategies to mitigate the risk associated with them. This list sheds light on technical threats and highlights the risk to the business. Note that this list only covers some of the potential vulnerabilities that can be present in a mobile application and it is not comprehensive.
Here are the OWASP Mobile Top 10 Risks.
- M1: Improper Platform Usage
- M2: Insecure Data Storage
- M3: Insecure Communication
- M4: Insecure Authentication
- M5: Insufficient Cryptography
- M6: Insecure Authorization
- M7: Poor Code Quality
- M8: Code Tampering
- M9: Reverse Engineering
- M10: Extraneous Functionality
Manage Security Risks with the OWASP Mobile Top 10
Let’s take a look at how you, as a mobile appsec engineer, can use the OWASP Mobile Top 10 to help better manage security risks in your mobile apps.
Angeli is an Android operating system (OS) mobile appsec engineer at a multinational software corporation that develops enterprise mobile apps to manage business operations and customer relations.
Angeli has been tasked with using the OWASP Mobile Top 10 to evaluate her organization’s mobile apps and verify that they’re secure. Let’s follow along as she does so.
The scenarios below describe examples of each risk but do not represent an exhaustive list of issues that could occur under each risk.
M1: Improper Platform Usage
This risk covers the misuse of a mobile OS feature or a failure to use platform security controls properly. It might include Android intents, platform permissions, misuse of biometric authentication mechanisms, password storage tools, or some other security control that’s part of the mobile OS.
During the evaluation of several of her company’s Android apps, Angeli notices that many of them are storing cryptographic keys on the file system. Because cryptographic keys are commonly used to secure particularly sensitive data they are a primary target for attackers.
An unauthorized user could use a variety of attacks to read the keys from the file system. Angeli knows that storing cryptographic material on the standard file system is against Android’s best practices and that her organization is at risk of improper platform usage. She circles back with the development team to help them implement a solution using the Android keystore system to store the cryptographic keys as securely as possible.
M2: Insecure Data Storage
This risk covers a case where an adversary attains a lost or stolen mobile device or executes malware or another repackaged app on the mobile device. Angeli evaluates the organization’s apps for this risk, and realizes that an app is storing usernames and credentials in plain text in system logs.
She circles back with the application development team to see if they performed a threat model on the app prior to release, in order to identify insecure storage as a possible risk. Noticing they did not perform one, she recommends that the application development manager incorporate threat modeling into the development process so that these bugs are identified before release.
Angeli further recommends that the development team identify sensitive data that the app processes, stores, or transmits, and validate that the data isn’t unnecessarily exposed. Lastly, Angeli informs the development team to create and implement a plan as soon as possible for remediating and redeploying the mobile app. Angeli works with the development team to perform a root cause analysis to uncover why the vulnerability was not identified before deployment.
M3: Insecure Communication
This risk covers a case where a threat agent might exploit vulnerabilities to intercept sensitive data while it’s traversing the mobile device’s carrier network and the internet. This can occur if an adversary compromises or monitors your local Wi-Fi network, or if there’s malware on your mobile device capturing the sensitive data in transit.
In evaluating her organization’s mobile apps for this risk, Angeli realizes that one of the apps fails to verify that the certificate offered is valid, and instead unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint, and leaves the app vulnerable to manipulator-in-the-middle (MITM) attacks through a transport layer security (TLS) proxy.
An MITM attack occurs when a perpetrator positions themselves in a conversation between two parties, such as a user and an application. The intention is to either eavesdrop or to impersonate one of the parties by making it appear as if a normal exchange of information is underway and capturing sensitive data.
To address this risk, Angeli works with the app development team to ensure the app only establishes a secure connection after verifying the identity of the endpoint server using trusted certificates in the keystore.
M4: Insecure Authentication
This risk covers a case where a threat agent exploits authentication vulnerabilities through attacks that use available or custom-built tools. In evaluating the organization’s mobile apps for this risk, Angeli realizes that an app uses a weak password configuration policy to simplify how the user enters a password. She works with the application development team to replace the 4-digit personal identification number (PIN) currently allowed as an authentication credential with a stronger authentication mechanism, to make it more difficult for adversaries to deduce the password.
M5: Insufficient Cryptography
This risk covers a case where a threat agent has physical access to data that’s been encrypted improperly, or uses mobile malware to take advantage of insufficient encryption on a mobile device. In evaluating her organization’s mobile apps for this risk, Angeli discovers that an app uses the Data Encryption Standard (DES) algorithm, which has been shown to have significant weaknesses. She works with the application development team to re-engineer the app to instead follow the National Institute of Standards and Technology (NIST) guidelines on recommended algorithms.
Sum It Up
Angeli’s organization is on the road to having more secure apps—but her work here isn’t done. In the next unit, find out how Angeli protects her organization’s apps against the rest of the Mobile Top 10.