Mobile application penetration testing

The test rests on two approaches, static and dynamic analysis. Static means taking the build apart without running it: decompiling the APK on Android, examining the IPA on iOS, searching for hardcoded keys, server addresses, and secrets directly in the code. Dynamic is the app running on the device, where we watch what it does with data and with the network. We follow the OWASP MASVS methodology and the MASTG testing guide, which name what should be verified on a mobile app.

OWASP doesn’t have one list for everything: a mobile app is measured against MASVS, not against the web OWASP Top 10. Specifically, we go after local storage, that is, what the app saves on the phone and whether that includes login tokens, personal data, or keys in readable form. Then the communication with the server: whether it runs over TLS and whether the app verifies the server certificate (certificate pinning, that is, pinning a specific certificate so a foreign one can’t be slipped in). And authentication and session management, that is, how the app handles login, logout, and token validity.

The last layer is interaction with the phone and the environment. We watch the permissions the app takes, the data it sends to logs and to backups, and its behavior on a device with an unlocked system. What differs here between Android and iOS is covered by the next section.

Android is more open, and its build is easier to take apart. An APK can be decompiled closer to source code, so with it more work goes to what’s visible in the code: hardcoded keys, addresses of test servers, hidden functions. We also watch the permissions the app requests and the components it exposes to other apps on the phone.

iOS is more closed, but with it more attention goes to local storage and resistance to running on a jailbroken device, that is, one with the system restrictions bypassed, where the attacker has full control over the phone. We look at whether the app recognizes such an environment and how it behaves in it, and whether sensitive data sits in the keychain or somewhere it can be read more easily.

When an app ships for both platforms, we test them side by side, because the same code behaves differently on Android and iOS, and we keep them apart in the report, so it’s clear which finding applies where.

A mobile app almost never stands alone; it talks to an API on the server, and some of the flaws are right there. We test the backend from the mobile client’s point of view: whether the server trusts what the app sends it, whether someone else’s data can be requested by swapping an identifier, and whether the permission check runs on the server, not just in the app the attacker holds in hand.

We keep the boundary clear. We test the backend as far as the mobile app talks to it. A purely web API and application we test separately, because a web client and the whole application’s business logic are a separate target with their own scope. The two can be combined into one engagement, and the effort is then added up.

The effort rests on the number of platforms (Android, iOS, or both), the size and complexity of the app, and how many roles and features it has. An app with login, payment, and chat is more work than a simple catalog; on mobile the number of screens and connected services decides, not the size of the installation file.

The effort is 4 to 6 person-days, and in calendar time it’s one to two weeks from the start to report delivery. The effort and duration of a mobile app test come from the number of platforms and the complexity, and you get the exact proposal after the scope is defined. One retest of fixed findings is included in the price.

First, the app build, that is, an APK on Android and an IPA on iOS, or access to a test version through TestFlight or internal distribution. Along with that, test accounts for every role the app has, so we can also test what a logged-in user sees, and a short description of the features, so the tester knows what the app is for and what shouldn’t be possible in it.

For an app with its own backend, we need to know which servers may be touched, so the test doesn’t hit someone else’s service or a production service that is out of scope. The rules of engagement and the testing window are agreed in advance, the same as with other tests.

It makes sense for apps that hold something valuable: login, payments, health or personal data, access to company systems. The more sensitive the data the app handles and the more of it sits right on the phone, the greater the impact of a single flaw in storage or in communication.

The best timing is before releasing a new app and after every major change, that is, when a payment, a login, or a connection to a new backend is added. A test just before launch catches flaws while they can still be fixed cheaply, not after an incident in production. What we find on mobile apps during tests is covered by our article on the most common mobile app flaws.