Comment auditer les requêtes générées par une application mobile Android ?

Posted on by Alban RAHIER
Reading Time: 5 minutes

Introduction

Request Map Generator est un outil disponible via webpagetest.org pour afficher une visualisation des différents noms de domaine appelés lors du chargement d’une page web. Les objectifs sont multiples :  

  • Identifier les services-tiers utilisés sur la page 
  • Identifier quels composants appellent ces services-tiers
  • Quantifier leur usage et leur impact afin de les challenger 
  • Identifier les principaux leviers d’actions

Par exemple, sur cette RequestMap, on constate que l’intégration de Twitter et Linkedin sont responsables du téléchargements de 71 ko de JavaScript. On observe également l’enchainement de requêtes conduisant jusqu’à Google. 

Le problème est que l’outil est mis à disposition pour auditer des sites web. Qu’en est-il des applications mobiles ? Nous proposons une démarche assez simple à mettre en œuvre pour générer la request map d’applications mobiles. 

HAR mapper

Le développeur de RequestMap, Simon Hearne, met également à disposition l’outil HAR mapper qui génère les mêmes request maps à partir de fichiers HAR. Les HAR sont des fichiers JSON qui permettent d’enregistrer le traffic capturé par divers outils d’analyse web comme les DevTools. Ainsi, plutôt que de demander un test entier de la suite webpagetest, on peut très bien choisir, d’enregistrer un fichier d’archive HTTP (.har) sur son propre PC. Cela nous permet de bâtir des RequestMaps plus précise, qui vont au-delà de la page d’accueil, tout en étant plus sobre numériquement. 

L’autre avantage est que l’on est désormais en mesure d’analyser des applications mobiles en utilisant un proxy SSL, sous condition que l’application autorise une certaine configuration réseau (voir Autoriser l’accès au certificat de Charles par l’application). 

CharlesProxy, le couteau-suisse du développeur 

Un proxy est un serveur qui sert d’intermédiaire entre le serveur et le client. Ce dernier envoie les requêtes au proxy qui est ensuite chargé de communiquer avec le serveur. Cela permet au proxy d’observer les différentes requêtes qui sont échangées. En outre, si le client accepte le certificat CA du proxy qui agira ainsi comme une Certificate Authority, le proxy sera capable de déchiffrer les requêtes HTTPS pour inspecter leur contenu. 

Charles Proxy est un serveur proxy dont l’usage est orienté pour les développeurs mobiles. En plus, d’agir comme un Proxy SSL, il propose de réécrire à la volée les headers (ou même le contenu !) des requêtes échangées. Il permet de tester la stabilité d’une application par rapport à des conditions de réseau, ou des problèmes serveur (throttling, répétition des requêtes, pas de cache, etc.). Dans notre cas, ce qui nous intéresse le plus est que Charles permet de sauvegarder les échanges client-serveur enregistrés sous forme de fichier .har. 

Nous proposons d’utiliser Charles Proxy car c’est un outil facile d’utilisation et assez complet mais sachez que d’autres serveurs proxy peuvent servir pour ce cas d’usage. Comme alternatives, il existe notamment mitmproxy, un outil en ligne de commande open-source ou HTTP toolkit très simple d’utilisation en version payante. 

Installer et configurer Charles 

Télécharger Charles et l’installer. Le serveur proxy est configuré automatiquement au lancement de Charles et les requêtes qui passent par lui sont enregistrées.  

Par défaut Charles n’active le SSL proxying uniquement pour une liste restreinte de noms de domaines. Pour changer ce comportement, aller dans Proxy > SSL Proxying settings. Vérifier que le SSL proxying est activé et ajouter une entrée * au tableau Include: 

Configurer le smartphone 

Il reste désormais à configurer notre smartphone Android pour se connecter à Charles. Le téléphone doit être dans le même réseau local que le PC sur lequel Charles est lancé. Dans les paramètres Wi-Fi, dans la configuration du réseau, définir le Proxy comme “Manual”. Rentrer l’adresse IP du PC sur lequel tourne Charles et définir le port de Charles (8888 par défaut). 

Si tout se passe bien, dès que le smartphone échange avec le réseau, Charles nous demande d’accepter ou de refuser la connexion au proxy. 

En acceptant, Charles devrait commencer à intercepter les échanges réseaux des applications. Néanmoins, les requêtes ne se font pas correctement. En effet, il nous reste à installer le certificat de Charles sur le téléphone. 

Installer le certificat de Charles 

Ouvrir le navigateur du smartphone, et visiter chls.pro/ssl. Le téléchargement du certificat se fait automatiquement. Si le fichier est ouvert, Android propose de l’installer, sous condition qu’un code PIN verrouille le téléphone. 

Attention à partir d’Android 11, la procédure est rendue plus compliquée. (Visiter l’aide de Charles pour installer le certificat sur d’autres systèmes). 

Il nous est désormais possible de transférer les requêtes émises par le processus de Chrome mais pas celles d’autres applications. En effet, pour raison de sécurité par défaut les applications Android n’acceptent que les certificats “système” (Ce n’est pas le cas pour iOS qui propose d’ailleurs une application Charles sur l’App Store). 

Autoriser l’accès au certificat de Charles par une application Android 

Trois cas de figure se présentent: 

  1. Vous disposez du code source de l’application. 

    Dans ce cas, il vous est facile d’autoriser l’usage de certificats CA “utilisateur”. Pour cela, ajouter un fichier `res/xml/network_security_config.xml` définissant les règles de configurations réseaux de l’application: 
<?xml version="1.0" encoding="utf-8"?> 

<network-security-config> 

<base-config cleartextTrafficPermitted="true"> 

<trust-anchors> 

<certificates src="system" /> 

<certificates src="user" overridePins="true" /> 

</trust-anchors> 

</base-config> 

</network-security-config>

Il faut également spécifier son chemin dans le AndroidManifest.xml: 

<?xml version="1.0" encoding="utf-8"?> 

<manifest ... > 

<application android:networkSecurityConfig="@xml/network_security_config" ... > 

... 

</application> 

</manifest>

Penser à ne garder cette configuration seulement pour l’application de debug, car elle peut engendrer des problèmes de sécurité MAJEURS. Voir la documentation officielle pour plus de détails. 

  1. Vous ne disposez que de l’apk de l’application. 

Dans ce cas il vous faudra décompiler l’application, utiliser la même méthode qu’en 2. et recompiler l’application et signer l’apk résultant. Pour cela certains outils (apk-mitm ou patch-apk) pourront vous aider dans le processus. La méthode n’est cependant pas garantie de fonctionner car l’application peut implémenter une vérification de la signature de l’apk. 

Attention ! En France, la décompilation d’un logiciel est strictement encadrée par la loi qui définit dans quels cas elle est légale. Dans le doute, assurez-vous d’obtenir l’autorisation de l’éditeur au préalable !

  1. Le smartphone de test est rooté. 

Dans ce cas, vous pouvez installer le certificat dans les certificats root du téléphone. 

Une fois que le certificat peut être utilisé par l’application, nous sommes en mesure d’inspecter les échanges entre le smartphone et le serveur. Pour générer un fichier .har, sélectionner toutes les requêtes, clic droit dans Charles sur les échanges réseaux > Export Session… et exporter en HAR.

Importer le fichier dans HAR Mapper, et nous avons notre Request Map !