Intents Android (2/2) : Deep Links, App Links, attaques et mitigationIntents Android (2/2) : Deep Links, App Links, attaques et mitigation

Ce second volet fait suite à Intents Android (1/2) : fonctionnement, sécurité et exemples d’attaques, qui posait le fonctionnement des Intents et l’intent hijacking. Il porte ici sur les Deep Links et les App Links : comment un lien peut être détourné par une application tierce, et comment s’en prémunir.

Qu’est-ce qu’un Deep Link Android ?

Les Deep Links Android permettent à une application mobile d’ouvrir directement une page ou une fonctionnalité interne depuis un lien web.

Par exemple :

• myapp://produit/123 peut ouvrir directement l’activité “produit 123” dans l’application myapp.
• myapp://auth?code=xyz peut servir à gérer une redirection OAuth après connexion.

Cette fonctionnalité permet d’offrir une expérience fluide à l’utilisateur :

• L’utilisateur clique sur un lien dans le navigateur → l’app s’ouvre directement.

On retrouve les deep links dans des cas comme l’authentification OAuth, les liens d’invitation, le suivi de colis, etc.

Cependant, si les deep links sont mal configurés, ils peuvent devenir une porte d’entrée pour des attaques.

Cas concret rencontré chez un client

Lors d’un pentest d’application mobile, nous avons trouvé une application Android qui utilisait l’authentification OAuth via Microsoft.

Le scénario normal :

1. L’utilisateur lance l’app.
2. Il est redirigé vers la page de connexion Microsoft.
3. Après login, Microsoft renvoie vers : myapp://auth?code=XXXX
4. L’app récupère le code, demande un jeton d’accès et connecte l’utilisateur.

C’est un scénario courant d’authentification via des fournisseurs tiers. Voyons maintenant comment il peut être exploité.

Tout d’abord, analysons le AndroidManifest.xml pour découvrir l’intent permettant cette fonctionnalité :

L’activité encadrée ci-dessus permet la réception du code OAuth généré par le provider Microsoft.

Un attaquant pourrait utiliser le même intent-filter et déclarer pouvoir réceptionner les URL deep link contenant myapp://msauth. Exemple :

Maintenant que l’application légitime et l’application malveillante sont toutes deux installées, un utilisateur souhaitant se connecter via OAuth verrait le comportement suivant :

L’utilisateur choisit la connexion via Microsoft.

Il se connecte à son compte Microsoft.

La première application est notre application malveillante, la deuxième est l’application légitime.

Code OAuth capturé dans notre application malveillante.

Maintenant que nous avons capturé le code, l’attaquant peut appeler le serveur OAuth pour obtenir un access token et accéder aux données du compte de l’utilisateur.

Mitigation et bonnes pratiques de sécurité pour les Deep Links

La solution consiste à transformer les deep links classiques en App Links, qui garantissent qu’une seule application valide pourra gérer le lien.

Concrètement :

1. Utiliser App Links

   • Définir android:autoVerify="true" dans le intent-filter.
   • Utiliser uniquement les schémas https.
   • Héberger le fichier .well-known/assetlinks.json sur le domaine associé.

Exemple de intent-filter sécurisé :

Fichier assetlinks.json attendu sur :

https://www.exemple.com/.well-known/assetlinks.json

Exemple du contenu du fichier :

[{
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
   	 "namespace": "android_app",
   	 "package_name": "com.example.myapp",
   	 "sha256_cert_fingerprints": ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
    }
}]

Android vérifiera automatiquement :

• Le domaine web → correspond au intent-filter
• Le package + certificat → correspond à l’application légitime

Ainsi, seule l’application validée pourra recevoir la redirection, empêchant toute application tierce de l’intercepter.