Mobile Application Security Testing: Android and iOS MAST Guide for Security Practitioners

The OWASP Mobile Top 10 (updated in 2024) provides the standard vulnerability taxonomy for mobile application security assessment.

M1: Improper Credential Usage Hardcoded credentials, API keys, and tokens embedded in the app binary or configuration files. These are extractable by anyone who decompiles the APK or examines the IPA. Every mobile security assessment should include a credential scan of the decompiled source.

M2: Inadequate Supply Chain Security Vulnerable third-party SDKs, malicious libraries, and dependency chain attacks. Mobile apps average 30+ third-party SDKs; each is an attack surface. Test by extracting the app's dependency list and checking each SDK version against known CVEs.

M3: Insecure Authentication and Authorization Weak authentication mechanisms, missing certificate pinning, broken session management, and insecure direct object references in API calls. Mobile apps frequently implement their own authentication logic rather than using platform-provided mechanisms, introducing errors.

M4: Insufficient Input and Output Validation Injection vulnerabilities in local SQLite databases, JavaScript injection in WebViews, path traversal in file operations, and XSS in hybrid apps. WebView security is particularly important: a WebView with JavaScript enabled and addJavascriptInterface can expose native device capabilities to injected JavaScript.

M5: Insecure Communication Missing certificate validation, acceptance of self-signed certificates, cleartext HTTP traffic, and weak TLS configuration. MITM attacks against improperly validated connections are a primary mobile attack vector.

M6: Inadequate Privacy Controls Excessive permission requests, logging of sensitive data, and unintentional data sharing with analytics SDKs. Many mobile apps log authentication tokens or PII to system logs accessible by other apps on rooted devices.

M7: Insufficient Binary Protections Missing root/jailbreak detection, missing debugger detection, missing obfuscation, and missing integrity checks. Without these controls, attackers can repackage apps with malicious modifications or dynamically analyze the app in a controlled environment.

M8: Security Misconfiguration Misconfigured Android permissions in AndroidManifest.xml, over-permissioned iOS entitlements, exported Android components (activities, services, providers) accessible to other apps, and debug configurations left in production builds.

M9: Insecure Data Storage Sensitive data in SharedPreferences (Android), NSUserDefaults (iOS), SQLite databases, external storage, or temporary files without encryption. This remains one of the most commonly found vulnerabilities across mobile apps.

M10: Insufficient Cryptography Use of deprecated algorithms (MD5, SHA1, DES, RC4), hardcoded encryption keys, predictable IV values, and ECB mode encryption. Crypto errors often produce data that looks encrypted but is trivially decryptable.

Android and iOS have fundamentally different security architectures that shape what you test and how.

Android unique attack surfaces:

• Exported components: Android activities, services, content providers, and broadcast receivers declared with android:exported="true" in AndroidManifest.xml are accessible to other apps on the device. Test exported components for injection, unauthorized access to data providers, and privilege escalation via intent redirection.
• Deep links and intent handling: Android deep links and intent filters can be exploited by malicious apps to launch exported activities with crafted parameters. Test all deep link handlers for open redirect and data injection vulnerabilities.
• External storage: Android apps that write sensitive data to external storage (/sdcard/) expose it to any other app with READ_EXTERNAL_STORAGE permission (or no permission on Android 10+ shared media). Scan for writes to external storage paths.
• APK analysis: Android APKs are ZIP archives containing compiled Dalvik bytecode (.dex files). Tools like jadx, apktool, and JADX-GUI can decompile the bytecode to readable Java-like source, making static analysis straightforward without access to the original source code.
• Accessibility services abuse: Android accessibility services APIs, while designed for assistive technology, are frequently abused by banking trojans to read screen content, simulate taps, and intercept credentials.

iOS unique attack surfaces:

• Keychain access groups: The iOS Keychain is the correct mechanism for storing credentials, but misconfigured kSecAttrAccessible values (particularly kSecAttrAccessibleAlways) make keychain items accessible even on locked devices. Test keychain storage for overly permissive accessibility attributes.
• URL scheme hijacking: iOS URL scheme handlers can be registered by multiple apps. A malicious app can register the same URL scheme as a legitimate app and intercept deep links containing OAuth tokens or other sensitive parameters.
• Universal links vs. custom URL schemes: Universal links (HTTPS-based) are more secure than custom URL schemes because they require the app to be registered as the verified handler for the domain. Test whether the app uses universal links for sensitive operations rather than custom URL schemes.
• Binary analysis on iOS: Without jailbreak, static analysis requires the encrypted IPA from the App Store to be decrypted first. Tools like frida-ios-dump can extract a decrypted IPA from a running device. Alternatively, developers can use debug builds for testing.

Static analysis examines the app binary without executing it. For Android, this means decompiling the APK; for iOS, it means analyzing the decrypted IPA binary and extracting embedded resources.

MobSF (Mobile Security Framework) is the most widely used open-source MAST platform. It performs automated static and dynamic analysis for Android APKs, iOS IPAs, and Windows App packages. Install it with Docker (docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf) and upload the app binary through the web interface. MobSF generates:

• AndroidManifest.xml analysis (dangerous permissions, exported components, debug flags)
• Hardcoded secrets scan (API keys, credentials, cryptographic keys)
• Dangerous API usage (reflection, exec(), crypto function calls)
• Certificate analysis
• Malware pattern matching
• CVSS-scored findings report

jadx is the most capable Android decompiler for manual analysis. After running MobSF for automated findings, use jadx-gui to browse the decompiled Java source and investigate specific areas MobSF flagged. Focus areas for manual review: authentication logic, cryptographic implementations, SQLite query construction (injection risk), WebView configuration, and network request handling.

Critical checks in AndroidManifest.xml:

• android:debuggable="true" on production builds
• android:allowBackup="true" (enables backup of app data via ADB without root)
• android:exported="true" on components that should be internal
• Missing android:permission attributes on exported content providers
• Broad intent filters on sensitive activities

Dynamic analysis tests the app while it runs, capturing API traffic, monitoring file system operations, and hooking into function calls at runtime.

Traffic interception with Burp Suite or OWASP ZAP: Configure the testing device to proxy through Burp Suite and install the Burp CA certificate. For Android 7+, user-installed CA certificates are not trusted by default for app network traffic (requires the app's network security config to allow user certificates or the device to be rooted). Bypass options:

• Use Android 6 or earlier (emulator) where user CAs are trusted
• Root the device/emulator and move the Burp certificate to the system trust store
• Patch the APK's network security configuration using apktool to remove certificate pinning or add user CA trust, then resign and install

Certificate pinning bypass: Many banking and enterprise apps implement certificate pinning. Common bypass approaches:

• Frida with the ssl-pinning-bypass script (works against common pinning implementations)
• objection framework (objection --gadget "com.app.name" explore then android sslpinning disable)
• APK patching via apktool to remove pinning code

Frida for runtime analysis: Frida is a dynamic instrumentation toolkit that injects a JavaScript bridge into a running process, allowing you to hook any function, read memory, and modify return values at runtime. Key uses in mobile testing: hook authentication functions to bypass checks, intercept cryptographic operations to see plaintext, and monitor file system and network calls.

Objection wraps Frida with a mobile-specific command interface for common tasks: disabling root detection, disabling SSL pinning, listing files, extracting the keychain (iOS), and dumping SQLite databases.

Data storage vulnerabilities are the most commonly found mobile security issue. Systematic testing requires examining every location where the app persists data.

Android data storage locations to test:

• SharedPreferences (/data/data/com.app.name/shared_prefs/) -- often used to store tokens and preferences; frequently unencrypted
• SQLite databases (/data/data/com.app.name/databases/) -- schema, data, and query construction
• Internal storage files (/data/data/com.app.name/files/)
• External storage (/sdcard/Android/data/com.app.name/)
• Logs (logcat output during authentication flows)
• Clipboard (apps that write sensitive data to clipboard)

iOS data storage locations to test:

• NSUserDefaults (plist files in Library/Preferences/)
• Keychain items with incorrect accessibility settings
• CoreData SQLite databases
• Cached HTTP responses (NSURLCache)
• Application snapshots (iOS saves a screenshot when the app goes to background -- may capture sensitive UI)

Authentication testing checklist:

• Can the session token be replayed from a different device?
• Does the app implement biometric authentication for high-risk operations, or only for app unlock?
• Is the authentication token stored in a secure location (Keychain on iOS, Android Keystore-backed EncryptedSharedPreferences)?
• Does the token expire after a reasonable inactivity period?
• Can BOLA (broken object-level authorization) attacks access other users' data by changing object IDs in API requests?
• Does the app implement proper logout (invalidating server-side sessions, not just deleting the local token)?

The average consumer app contains 30+ third-party SDKs. Enterprise apps typically have 15-25. Each SDK has its own data collection practices, permissions usage, and vulnerability history -- and they run with the same permissions as the app itself.

High-risk SDK categories:

• Analytics SDKs (Firebase Analytics, Amplitude, Mixpanel): Often collect device identifiers, IP addresses, and screen content. Verify what data is transmitted and whether it includes sensitive user input.
• Advertising SDKs (Google AdMob, Meta Audience Network): Historically have been vectors for ad fraud malware. Review the SDK version and recent CVE history before accepting.
• Social login SDKs (Facebook SDK, Google Sign-In): Ensure the SDK version is current; Facebook SDK in particular has had multiple high-severity vulnerabilities related to token storage and deep link handling.
• Crash reporting SDKs (Crashlytics, Sentry, Bugsnag): May capture stack traces, local variable values, and custom breadcrumbs that include sensitive data. Review what data is logged at crash time.

SDK assessment process: Extract the list of third-party libraries from the APK (using MobSF or manually from the decompiled source). For each SDK: check the version against the NVD for known CVEs, review the SDK's privacy documentation for data collection practices, and verify that the SDK does not request permissions beyond what the app itself needs.

Supply chain risk: If a dependency is abandoned (no commits in 12+ months, no response to security issues), evaluate replacing it. Abandoned SDKs are increasingly targeted by attackers who acquire control of the package namespace or the maintainer's account.