Essential Considerations for an Effective Mobile App Pen Test

In any information security program, mobile applications should be considered for inclusion in penetration tests. No matter the size of an application, it may serve as an avenue of attack against your environment or users and the threat potential of these applications is similar to that of web applications. In fact, some mobile apps are effectively web apps with a wrapper while others utilize a unique frontend, but with a backend web API.  

Yet there's still some nuance as mobile applications are still inherently different from web applications in many respects. To help delineate, we’ve provided a list of questions to ask your provider; these will help identify if the provider is right for you, as well as reduce the risk of potential miscommunications: 

How long will the test take? 

A suspiciously short timeline may indicate a scope miscommunication, or at worst, a low-quality provider. However, keep in mind that overall scope dictates engagement length, as well as the number of resources assigned. 

We can’t speak for all providers, but at Schellman, we typically expect 1 week for most mobile applications. For large or multiple applications, 2 weeks is about average. 

Will testing include the underlying API used for communication? 

If the underlying backend API is not included, then only the core mobile application will be tested. If that is the case, then web or API vulnerabilities which affect your backend infrastructure would not be discovered. The underlying API should be included with the mobile app assessment – however, you should check with your provider rather than make assumptions. 

Do you need a “test” or “security” build (i.e. a build with security settings disabled)?

When your mobile team deploys an application, there’s a decent chance that there are some protections enabled on the application binary: 

• TLS Pinning: Requires application communications to only trust specific certificates. 
• Jailbreak Detection: Identifies if the device is jailbroken (“rooted”) before application launch. 
• Emulation Detection: Identifies if the device is being emulated before application launch. 
• Sideload Detection: Identifies if the application is being sideloaded before launch. 

As advocates of protective initiatives, we’re not here to speak ill of any security measures. However, since these are all checks which are performed by the application itself, an attacker with enough time can bypass these controls. Therefore, if an app has any of these protections enabled, it will increase the amount of time required to perform the test. This will ultimately result in less time spent on frontend and backend testing.  

The good news is that your mobile team should be able to produce a specialized app build without any of these protections enabled. These builds are typically called “security” or “dangerous” builds and are meant only for developer and pen test usage. 

Do you perform reverse engineering of the mobile builds for static and dynamic analysis? 

While we've covered the importance of backend testing, the core application binary itself still needs to be tested as well. Identifying a vulnerability here will uncover issues which may lower your mobile device's security or even that of your production environment. Therefore, this is a minimal viable product of any mobile assessment. 

Do you review the third-party libraries and modules used to build the application? 

Equally as important as your product’s code base are the libraries which were used to build said code base. At a minimum, we’d expect an examination of these libraries for known vulnerabilities and ideally, your provider will determine exploit feasibility for these vulnerabilities.

Do you review data at rest for sensitive data vulnerabilities? 

In some cases, sensitive data such as passwords, tokens or PII may be stored in an unsafe resident manner. This leads to that data being accessible in the event of a stolen device or device backup. It’s best practice to review sensitive data storage and proactively identify those potential vulnerability risks.

Do you review interfaces and inter-process communications (IPC) between apps? 

Applications often communicate with one another. For example, you can send a picture from your web browser to a text message. These IPCs are flexible, allowing for applications to communicate with little to no user interaction. Therefore, it’s worth testing to see if a rogue application can communicate with another process to retrieve sensitive data or perform an action. 

Choosing the Right Provider for an Effective Mobile Pen Test

To ensure an effective mobile application test, it’s essential to select a provider that understands the unique threats and vulnerabilities associated with mobile apps. A comprehensive mobile app test should include static, dynamic and backend testing. Choosing the right provider ensures that your mobile application is thoroughly evaluated against real-world attack scenarios, helping to uncover potential security gaps before they can be exploited. Look for a provider with proven expertise, a deep understanding of platform-specific risks, and a methodology that aligns with the industry best practices we've outlined here. 

If you find yourself needing assistance with a penetration test, feel free to fill out our brief pen test scoping questionnaire and a pen test leader at Schellman will get back to you shortly. 

In the meantime, discover other insightful tips for effective pen tests in these additional resources:

• Get the Pen Test Report You Deserve: A Leader’s Guide 
• The Insider’s Guide on Getting A Better Web App Pen Test 
• Don’t Buy A Network Pen Test Until You Ask These Questions 
• Quality Penetration Tests: What Your Provider Won't Tell You