M1:2016 Improper Platform Usage

📋 What Is It?

Improper Platform Usage covers every case where an app misuses a mobile operating-system feature or fails to use a platform security control correctly. The OS ships permission models, the Keychain and Keystore, secure IPC, App Transport Security, biometric APIs and WebView sandboxing - and this category is what happens when the app fights, ignores, or misapplies them.

The distinguishing idea is direction: the platform already offers the secure way to do the thing, and the app takes a weaker path. A secret in SharedPreferences instead of the Keystore. An exported Activity that should have stayed private. ATS disabled to make one cleartext call work. A biometric prompt whose callback returns a boolean instead of unlocking a real key.

M1 OWASP Rank 2016

OS Guardrails Bypassed

Config Usual Root Cause

⚠️ Common Exploits

Exported IPC: Activities, Services, Receivers, Providers reachable by any installed app
Wrong Secret Store: tokens in SharedPreferences/UserDefaults/plist
ATS / Cleartext Enabled: usesCleartextTraffic=true, global ATS exceptions
Boolean Biometrics: auth result not bound to a cryptographic key
WebView Bridges: addJavascriptInterface plus file access and untrusted URLs
Backup Leakage: sensitive files included in cloud or ADB backups
Over-Requested Permissions: broad grants that widen the blast radius
Weak Custom Permissions: signature downgraded to normal

🔴 Attack Flow

1. Pull the APK/IPA and read the manifest / Info.plist
↓
2. List exported components, permissions, ATS and backup settings
↓
3. Invoke exported components from a malicious app
↓
4. Read secrets from preferences, plists, or a device backup
↓
5. IMPACT: Data theft or privileged actions from a zero-permission app!

❌ Vulnerable Code

<!-- Bad: exported to every app on the device, no permission -->
<activity android:name=".TransferActivity" android:exported="true" />
<provider android:name=".NotesProvider" android:exported="true"
          android:grantUriPermissions="true" />

<!-- Bad: cleartext allowed, everything backed up -->
<application android:usesCleartextTraffic="true"
             android:allowBackup="true" />

// Bad: a bearer token in plaintext preferences
prefs.edit().putString("auth_token", token).apply();

// Bad: biometric result is just a boolean the attacker can hook
biometricPrompt.authenticate(info)   // onSuccess → unlockUi(); no key involved

// Bad: native bridge on untrusted content
webView.addJavascriptInterface(new Bridge(), "android");
webView.settings.javaScriptEnabled = true;
webView.settings.allowFileAccess = true;
webView.loadUrl(intent.getStringExtra("url"));   ← attacker-controlled
                

✅ Secure Code

<!-- Good: private by default; export only with a signature permission -->
<activity android:name=".TransferActivity" android:exported="false" />
<service  android:name=".SyncService" android:exported="true"
          android:permission="com.example.permission.SYNC" />
<permission android:name="com.example.permission.SYNC"
            android:protectionLevel="signature" />

<!-- Good: no cleartext, no blanket backup -->
<application android:usesCleartextTraffic="false"
             android:allowBackup="false"
             android:networkSecurityConfig="@xml/network_security_config" />

// Good: hardware-backed key store, unlocked by biometrics
val spec = KeyGenParameterSpec.Builder("auth_key", PURPOSE_ENCRYPT or PURPOSE_DECRYPT)
    .setUserAuthenticationRequired(true)          // biometrics unlock the KEY…
    .setInvalidatedByBiometricEnrollment(true)
    .build()
biometricPrompt.authenticate(info, BiometricPrompt.CryptoObject(cipher))
// …and the token is only decryptable after a real authentication

// Good: locked-down WebView on trusted content only
webView.settings.javaScriptEnabled = false
webView.settings.allowFileAccess = false
webView.loadUrl("https://app.example.com/help")     // fixed, validated origin

// Good (iOS): Keychain with the strictest workable accessibility
kSecAttrAccessible: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
                

✓ Prevention Checklist

Export components only when required, and protect them with signature permissions
Store secrets in the Keystore/Keychain - never in preferences, plists, or files
Choose the strictest workable Keychain accessibility class
Keep ATS on; disallow cleartext traffic app-wide
Bind biometric authentication to a cryptographic key, not a boolean
Disable JavaScript, file access, and native bridges in WebViews unless required
Load only fixed, validated origins into a WebView
Exclude sensitive data from backups
Request the minimum permissions, at the moment of use
Validate every input arriving over IPC and deep links
Re-review the manifest / Info.plist on every release

🔍 Detection & Tools

Static:

MobSF apktool jadx semgrep-mobile

Dynamic:

Frida objection drozer adb / Android Studio

How to Test:

Enumerate exported components and invoke each from a test app
Dump shared_prefs, plists, and the app sandbox for secrets
Check ATS/cleartext, backup, and debuggable flags in the built artifact
Hook the biometric callback and see whether data still decrypts
Feed hostile deep links and IPC extras to every entry point

🌍 Real-World

These are documented incident classes - recurring patterns rather than single CVEs.

Exported content providers: another installed app queries private notes, messages, or account rows with no permission at all.
Tokens in plaintext preferences: a device backup or a rooted-device dump yields long-lived session tokens.
Global ATS exceptions: disabling transport security "for one legacy endpoint" downgrades the entire app to interceptable traffic.
Boolean biometrics bypassed: a runtime hook flips the success callback and the app unlocks without any real authentication.
WebView bridges reached from untrusted pages: a JavaScript interface exposed to attacker-controlled content leads to file or account access.

📌 Quick Tips

DO NOT export components you do not need to
DO NOT keep secrets outside the Keystore/Keychain
DO NOT disable ATS or allow cleartext globally
DO tie biometrics to a real cryptographic key
DO lock WebViews down and pin their origins
DO audit the manifest every release

📜 Compliance

Related Standards:

OWASP Mobile Top 10 2016 - M1
Maps to M8:2024 Security Misconfiguration
OWASP MASVS PLATFORM-1 … PLATFORM-3
CWE-926 Improper Export of Android Application Components
CWE-276 Incorrect Default Permissions

📱 Improper Platform UsageMobile 2016