Bonjour à tous et à toutes !

Un petit article destiné aux développeurs web, à ceux qui s'intéressent aux questions de vie privée, ainsi qu'aux bidouilleurs en tout genre
Quand on évoque un proxy, on pense souvent à une manière de s'anonymiser sur le web. Certes, mais quid d'un proxy de type debugging pour développer ?
Pour cela, il faut que le proxy propose des comportements spécifiques, dit autrement, des règles, qui, lorsqu'elles sont réalisées pour une url (ou des headers, ...) permettent de charger un fichier à la place d'une page web, de redédiriger vers une autre page web, de modifier la réponse de retour à la volée, etc.

On peut imaginer différents cas d'usages, tels que :
- faire des mocks de webservices lors d'un développement front-end ;
- visualiser le traffic d'une application, voire de tout un système (voir plus bas) ;
- mocker une application qui n'est plus fonctionnelle (licence, serveur HS, le serveur a évolué et l'application n'est plus maintenue i.e changement d'url, non support du HTTPS ou de la redirection HTTP vers HTTPS, ...).

Il s'agit à part entière d'une procédure basée sur un exploit de type "Man In The Middle", de plus, dans certains de ces cas, on s'approche ici du reverse engineering ; je vous laisse seuls juges de ce que vous avez le droit/ l'intention de faire.


Il y a 2 modes d'usages bien distincts :

Le traffic est en HTTP (le cas simple)

Vous pouvez utiliser un proxy, ou développer une application web classique qui accepte toutes les requêtes à la racine du serveur. Dans ce second cas, vous pouvez choisir les technologies de votre choix et retourner la réponse de votre choix (depuis le système de fichier, auto-générée, ou chargée depuis une url).
Cette solution est très évolutive car vous pouvez développer ce que vous avez besoin, notamment y inclure de la logique.

C'est adapaté si vous mockez votre application, mais pas pour faire transiter tout le traffic d'un système, car les requêtes HTTPS planteront lors du CONNECT.


Le traffic est en HTTPS ou mixte HTTP/ HTTPS (le cas réel)

Dans ce cas, une appli custom devient complexe, car elle doit signer les certificats, il est préférable d'utiliser un proxy de debugging.

Dans le domaine 2 applications sont assez connues :
- Fiddler (.NET), que j'ai beaucoup utilisé par le passé
- Charles, probablement le plus avancé, mais ce dernier est payant

On m'a parlé d'une alternative open source récente James (NodeJS), c'était l'occasion de l'essayer. Elle s'avère fonctionnelle bien qu'encore peu mature.


Un cas d'usage

Proxyfier le réseau de votre Android
- sélectionnez votre wifi
- maintenez la sélection sur ce dernier
- dans la popup contextuelle, qui apparaît, cliquez sur "Gérer les paramètres réseau"
- Dans "Proxy" choisissez "Manuel(l)e", puis saisissez les coordonnées de votre proxy IP et PORT (pour mon installation James, par défaut 1338)


Sur votre ordinateur
- Téléchargez James
- npm install (ça dure un petit moment, notamment si vous n'utilisez pas NodeJS habituellement ; par ailleurs, en cas de souci de "syntax error", mettez à jour votre installation de NodeJS)
- npm start
L'installation est prête pour du HTTP. Vos applications en HTTP fonctionneront correctement (pas celles en HTTPS).

Pour le HTTPS, la procédure est ici.
Le dossier de configuration n'est peut-être pas celui annoncé dans la documentation (en tout cas, le mien était différent). Vous pouvez connaître ce dossier en survolant le petit label indiquant si oui ou non, la configuration HTTPS est effective.

Il ne reste plus qu'à regarder le traffic et à écrire vos propres règles pour redonner vie aux applications qui ne fonctionnent plus, filtrer les appels de publicité, ajouter des logs, ... bref, suivre votre inspiration.


Et si à tout hasard vous tentiez l'expérience, combien pensez vous qu'une application Android fait-elle de requêtes lorsque vous la démarrez ? Et quelles sont les informations qu'elle remonte ? Et quand les applications sont fermées ?



Amusez-vous bien !


Pour les breton(ne)s, le temps est à la neige, si vous prenez la route, soyez vigilants.