Unvalidated Intent Extras

← Input Validation (OWASP Mobile M4)

unvalidated_intent_extras   MEDIUM

Description

Intent extras trusted as-is, enabling privilege escalation.

How it works

An exported activity reads Intent extras (user_id, is_admin, redirect) and trusts them without validation, so a malicious app (drozer or adb) sets is_admin=true and escalates privileges or forces an internal redirect. On Android this actually starts DVMA’s real exported component with the attacker-supplied extras and reads back the privileged op it ran; the in-memory panel is the offline contrast. Handle the crafted intent below.

How to exercise it. DVMA is the harness - open this module from the home index and tap the demo action. The screen ships the malicious input and simulates the attacker (e.g. the companion app, crafted intent, or scanned payload) in-process, and the evidence panel prints the proof. The Tools (optional) and Attack inputs below are only needed to reproduce the exploit end-to-end on a real device.

Exploit steps

1. Set up. Build DVMA with a flavor that enables the Input Validation (OWASP Mobile M4) category (e.g. --dart-define-from-file=config/flavors/dev.json) and run on an Android emulator you control. The demo needs no external tooling; for the optional on-device reproduction the relevant tools are: adb, drozer, jadx.
2. Locate the target. From the home index, open Unvalidated Intent Extras (unvalidated_intent_extras). The How it works section above describes this module’s specific weakness; the screen states the intended-secure behavior and exposes the vulnerable action.
3. Exploit. Feed the crafted/malformed input (serialized blob, intent extra, media file, deep link) into the parsing path and confirm the app trusts it - state change, crash/DoS, or code path it should reject.
4. Observe the evidence. Trigger the vulnerable action and read the evidence panel - it prints the concrete proof (leaked value, accepted replay, executed payload, or unauthorized result).
5. Contrast with the secure path. Run the module’s secure/hardened action (where provided) and confirm the same attack is rejected - this is what a correct implementation should do.
6. Map it back. Cross-reference the MASTG v2 test(s) MASTG-TEST-0375 for the canonical procedure and remediation.

Tools (optional)

• adb
• drozer
• jadx