Mettre en place Burp Suite : principes du proxy d’interception

Un navigateur est conçu pour cacher la plomberie du web. Un testeur, lui, a besoin de la voir. Le proxy d’interception est une fenêtre ouverte sur les échanges entre le navigateur et le serveur : on peut les lire, les mettre en pause et les rejouer. Dans cette leçon, vous comprenez le principe et vous préparez votre poste, uniquement pour un usage en laboratoire.

L’idée du « proxy »

Un proxy est un intermédiaire. Imaginez un facteur qui, avant de remettre votre courrier, vous le montrerait pour que vous puissiez le lire, le noter, voire le corriger avant qu’il parte. Un proxy d’interception se place entre votre navigateur et le serveur web. Chaque requête HTTP passe par lui. Vous choisissez de la laisser filer ou de la retenir.

Souvenez-vous de la structure d’une requête HTTP vue dans le cours sur les réseaux : une ligne de départ (méthode, chemin), des en-têtes, parfois un corps. Le proxy vous montre tout cela en clair, y compris le contenu des connexions HTTPS, à condition de configurer correctement la confiance (nous y venons).

Burp Suite, un outil du métier

Burp Suite est l’un des outils de référence des testeurs d’applications web. Il existe une édition communautaire gratuite, suffisante pour apprendre. Ses modules, présentés ici de façon générale :

D’autres outils open source jouent des rôles voisins ; l’important est de comprendre le principe, qui reste le même d’un logiciel à l’autre.

Installer et configurer, étape par étape

Travaillez dans votre machine virtuelle Kali Linux (voir le cours précédent) ou sur votre poste, mais toujours avec une application d’entraînement locale comme cible.

1. Installer l’outil depuis la source officielle de l’éditeur ou, sous Kali, depuis le dépôt de la distribution.
2. Démarrer le proxy : par défaut, il écoute sur l’adresse locale de la machine, sur un port que l’interface indique (souvent 8080).
3. Configurer le navigateur pour qu’il envoie son trafic vers ce proxy. Le plus simple : utiliser le navigateur intégré à l’outil, ou un profil de navigateur dédié à vos tests, pour ne pas mélanger avec votre navigation personnelle.
4. Installer le certificat de l’autorité du proxy dans ce navigateur dédié. Sans lui, le navigateur affichera des alertes pour chaque site HTTPS. Pourquoi ? Parce que le proxy déchiffre puis rechiffre le trafic avec son propre certificat : c’est, techniquement, une interception volontaire. Votre navigateur dédié doit donc faire confiance à ce certificat.
5. Vérifier : visitez votre application d’entraînement et regardez l’historique. Les requêtes doivent apparaître.

Lire une requête interceptée

Voici une requête générique, telle que vous la verrez dans l’historique, sur une application d’entraînement locale :

POST /login HTTP/1.1
Host: appli-entrainement.local
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123
Content-Length: 31

username=etudiant&password=exemple

Lisez-la comme un enquêteur : la méthode (POST : on envoie des données), le chemin (/login), le nom d’hôte, le cookie qui identifie la session, et le corps qui contient les champs du formulaire. Chaque élément est une entrée potentielle que l’application doit traiter avec méfiance. C’est exactement ce qui nous intéressera dans les chapitres suivants.

Intercepter, observer, rejouer

Deux gestes de base à maîtriser dès maintenant :

• Intercepter : activer l’interception retient chaque requête avant son départ. Vous pouvez l’examiner, la modifier si besoin pour votre expérience, puis la transmettre. Désactivez l’interception quand vous n’en avez plus besoin, sinon le navigateur semble « figé ».
• Rejouer : depuis l’historique, envoyez une requête vers le module de rejeu. Vous modifiez une valeur, vous renvoyez, vous comparez les réponses. C’est la façon la plus propre d’expérimenter : on garde le contrôle de chaque essai.

Cette approche « une modification, une observation » est la clé. Changer dix choses à la fois ne permet pas de savoir laquelle a produit l’effet.

À vous de jouer

Si votre application d’entraînement n’est pas encore installée (elle l’est dans la leçon suivante), faites cet exercice avec une page web locale de votre laboratoire, ou revenez-y après la leçon 3. Les objectifs :

1. Configurez le navigateur dédié et vérifiez que le trafic passe par le proxy.
2. Repérez dans l’historique une requête POST et une requête GET.
3. Pour chacune, listez les éléments d’entrée : chemin, paramètres d’URL, en-têtes, cookies, corps.

Il nous faut maintenant une application à observer, légalement. C’est l’objet de la leçon suivante.