It is crucial to recognise that what you develop should serve its core functionality and not introduce a new attack vector into user devices.

The compromise of a user’s device via the products you provide to them can lead to the loss of confidentiality, integrity and availability of the data within your platform and the user’s device as a whole. This can lead to reputational damage caused by mistrust in your applications.

By baking cybersecurity testing into the development lifecycle of your applications, you can prevent the exploitation of the application and its users.

The rest of this article provides an overview of what to expect from the mobile security testing process.

What about user devices?

The first thing to consider is the mobile device ecosystem. Hardware and software versions and types of applications vary across user devices.

If a single application is compromised, modern devices have security mechanisms to prevent an attacker from accessing other parts of the device. Thus, an attacker would be limited to accessing application-specific files and device functionality. Attackers will aim to escape this application sandbox.

To accomplish this, an attacker will look for weaknesses in devices to compromise and escalate privileges. A select number of the most popular devices and recent software versions would be chosen for testing to limit the scope of work.

Google’s Project Zero has a great series of blogs. As an example, here’s a technical write-up discussing breaking out of the Android application sandbox.

What are we looking for?

Vulnerabilities observed in mobile applications can vary depending on the functionality and complexity of the application.

A summary of the most common vulnerabilities in modern mobile applications has been compiled by the OWASP community.

How does the application work?

So how does this application work? What functionality does it provide to the user? These questions can tell you a lot in the testing process when first surveying the application.

Performing certain functions on a device requires the user to grant access to the application, which expands the attack surface. Data often flows in and out of the application to broker communication between the user and a web service.

We will use dynamic analysis to run through the application’s functionality to see how it can be manipulated into returning sensitive information or performing actions that the user is not permitted. This can include looking for sensitive files being mishandled on the file system or rooted devices having the ability to bypass security controls.

This process will require manual work at first but can be automated with more and more exposure to the application.

Who is the app talking to?

How is the app getting information? Where is user information being stored? On the device, or somewhere else? Are communications encrypted?

While we use the application, we can listen on the device for traffic being generated. Most mobile applications will interact with a server on the backend.

As we look through the application’s functionality, we’ll observe the network traffic, looking for any data being handled insecurely. This lets us see how the application interacts with the backend and whether we can exploit functionality on the backend to gain control over the server or exfiltrate confidential data.

Expanding visibility

Running the application won’t show us everything that’s under the hood. During white-box testing, we can look at the code and any pipelines it traverses during development. Then, with a combination of manual and automated techniques, we will identify existing vulnerabilities and provide insight into how they manifested and demonstrate strategies and techniques to avoid new vulnerabilities in the future.

What can a threat actor see?

We won’t always have access to source code. To simulate an attacker’s viewpoint, we can conduct testing without source code and use tools and techniques to extract firmware, application packages, and binaries from devices. While any obfuscation on the code itself may delay testing, we will inevitably create a clear picture of how the application operates.

Can performance-increase compromise security?

Does this application handle video, animated images, or perform any other GPU or CPU intensive tasks?

Sometimes to meet the specific performance requirements of your applications, you are required to write custom code to run natively on devices. The use of native libraries is often neglected in application testing, but if vulnerabilities exist and are exploited, the results can be significant, often leading to remote code execution.

A comprehensive test will pay special attention to any additional libraries being loaded by an application. This can introduce new risks to the application, so it’s critical to harden protections around these components and conduct rigorous testing.

How can we leverage mobile application security testing?

Cyber security will act as an enabler in this space to improve the efficiency and speed of development. It is becoming an industry standard to provide users with the assurance that their applications have been thoroughly tested and protected against common flaws.

Mobile application security testing can be a great addition to penetration testing engagements or integrating with your development life cycle.

The OWASP Mobile Security Testing Guide provides a good summary of factoring security into the Software Development Life Cycle.