Extraire un jeton de session enregistré dans le bac à sable d'une appli Android

Chaque appli Android dispose d'un bac à sable de stockage privé à /data/data/<package>. À l'intérieur, le dossier shared_prefs contient les SharedPreferences de l'appli, de simples réglages clé/valeur écrits sous forme de fichiers XML en clair. Les applis utilisent ce stockage pour tout, d'un indicateur de mode sombre à, moins judicieusement, un jeton de session connectée. Le répertoire est privé au sens où les autres applis ne peuvent pas le lire, mais ce ne sont jamais que des fichiers sur le disque.

Cette distinction compte dès qu'on a un accès au niveau fichier. Un appareil rooté, une sauvegarde non chiffrée, une image forensique ou, comme ici, un shell adb, peuvent tous accéder à /data/data/com.example.acmebank/shared_prefs et ouvrir auth.xml. L'appli bancaire y a enregistré sa session sous la forme <string name="session">sess_4f91c2ad7e_prod</string>. Rien dans sa lecture ne nécessite de casser l'appli ; la valeur est là, en clair, à côté du nom d'utilisateur.

Un jeton de session est un identifiant de type bearer : le présenter suffit pour agir en tant qu'utilisateur connecté, sans mot de passe. Un jeton récupéré depuis le stockage local peut donc souvent être rejoué directement contre l'API de l'appli pour détourner le compte. C'est pourquoi stocker une session active en clair dans les préférences est considéré comme une vraie vulnérabilité, pas un simple défaut cosmétique : la frontière du bac à sable protège contre les autres applis, pas contre quelqu'un qui a accès au système de fichiers de l'appareil.

• Regarder d'abord dans le dossier databases. Le jeton se trouve ici dans shared_prefs/auth.xml, pas dans la base SQLite accounts.db - les préférences sont l'endroit le plus simple où une appli planque une session.
• Lire le bac à sable de la mauvaise appli. com.android.systemui est l'interface système, pas la banque ; le package cible est com.example.acmebank.
• Ouvrir settings.xml au lieu de auth.xml. settings.xml contient le thème et la langue ; la session de connexion se trouve dans auth.xml.
• Supposer que le jeton est chiffré. Il est stocké sous forme de chaîne en clair que l'appli relit telle quelle, donc lire le fichier suffit.

Le stockage local d'une appli n'est pas un endroit sûr pour une credential de type bearer. Les corrections consistent à garder le jeton hors des fichiers lisibles et à limiter les dégâts si le stockage est exposé :

• Stocker les jetons de session avec l'Android Keystore ou EncryptedSharedPreferences pour que la valeur sur le disque soit chiffrée au repos, et non en XML en clair.
• Garder les jetons de session à durée de vie courte et les lier à l'appareil, pour qu'un jeton copié expire rapidement et ne puisse pas être rejoué ailleurs.
• Exclure les fichiers sensibles des sauvegardes (définir android:allowBackup="false" ou utiliser des règles de sauvegarde) pour que le jeton ne soit pas exporté dans une sauvegarde en clair.
• Détecter les appareils rootés ou modifiés et refuser d'y persister des identifiants à longue durée de vie.

Si un jeton de session a été exposé sur le disque, invalider cette session côté serveur et forcer une nouvelle authentification : un jeton bearer divulgué reste utilisable tant que le serveur continue de l'accepter.