Tutoriel Burp Suite : trouvez les vulnérabilités web étape par étape

TL;DR

Burp Suite est l'outil de test de sécurité des applications web le plus utilisé, adopté par plus de 70 000 organisations dans le monde. Ce guide accompagne les débutants dans tout le processus : installer Burp Community Edition, configurer le proxy du navigateur, intercepter et modifier les requêtes HTTP, explorer une application web et utiliser Repeater et Intruder pour trouver des injections SQL et du cross site scripting dans DVWA. Aucune expérience préalable en pentesting requise.

La page de connexion avait l'air normale. Un formulaire simple avec deux champs, un bouton d'envoi, rien d'inhabituel. Mais quand Carla, une pentester junior lors de sa première mission client, a tapé une simple apostrophe dans le champ nom d'utilisateur et cliqué sur envoyer, l'application a répondu avec un message d'erreur complet de la base de données. Noms de tables, références de colonnes, la requête SQL elle-même, tout affiché à l'écran en texte brut. Elle avait trouvé une vulnérabilité d'injection SQL en moins de trente secondes, non pas parce qu'elle était un génie, mais parce qu'elle savait utiliser Burp Suite.

Cette découverte a changé toute la mission. L'injection SQL a conduit à l'extraction complète de la base de données, qui a révélé des mots de passe stockés en clair, ce qui lui a donné accès au panneau d'administration. Une apostrophe. Un outil. Un compromis complet documenté dans son rapport avant le déjeuner.

Burp Suite est l'outil qui a rendu cela possible. Non pas en automatisant tout, mais en donnant à Carla une visibilité complète sur chaque requête et réponse HTTP circulant entre le navigateur et l'application. Elle pouvait voir ce que l'application faisait, modifier ce qu'elle recevait et tester comment elle répondait. Cette visibilité est ce qui sépare quelqu'un qui clique sur des boutons de quelqu'un qui trouve des vulnérabilités.

Qu'est-ce que Burp Suite et pourquoi c'est important

Burp Suite, développé par PortSwigger, est une plateforme intégrée de test de sécurité des applications web. Il fonctionne comme un proxy qui s'intercale entre votre navigateur et l'application web cible, capturant chaque requête et réponse pour inspection et manipulation. Considérez-le comme un microscope de sécurité pour le trafic HTTP.

L'outil est important car les applications web sont la surface d'attaque principale pour la plupart des organisations. Selon l'OWASP, les failles d'injection incluant l'injection SQL et le cross site scripting figurent parmi les 10 principaux risques de sécurité des applications web chaque année depuis la première publication de la liste en 2003. Le coût moyen d'une violation de données causée par une vulnérabilité d'application web a atteint 4,88 millions USD en 2024 selon le rapport annuel d'IBM. Trouver ces vulnérabilités avant les attaquants n'est pas facultatif. C'est le travail principal des pentesters d'applications web.

Burp Suite Community Edition est gratuit et inclut tout ce dont vous avez besoin pour démarrer : le Proxy pour intercepter le trafic, Repeater pour renvoyer manuellement des requêtes modifiées, Intruder pour la livraison automatisée de payloads (avec limite de débit dans la version gratuite), Decoder pour encoder et décoder des données, et Comparer pour repérer les différences entre les réponses. Plus de 60 % des offres d'emploi en tests de pénétration mentionnent Burp Suite comme compétence requise ou préférée. L'apprendre n'est pas seulement éducatif. C'est un investissement professionnel.

Installer Burp Suite Community Edition

Burp Suite fonctionne sur Windows, macOS et Linux. Il nécessite Java, mais l'installateur intègre son propre runtime Java, vous n'avez donc rien à installer séparément.

Téléchargez la Community Edition depuis la page de téléchargement officielle de PortSwigger. Choisissez l'installateur pour votre système d'exploitation. Sur Linux, le téléchargement est un script shell :

chmod +x burpsuite_community_linux_v2024_x_x.sh
./burpsuite_community_linux_v2024_x_x.sh

Sur macOS, ouvrez le fichier .dmg et glissez Burp Suite dans votre dossier Applications. Sur Windows, lancez l'installateur .exe et suivez les instructions.

Lancez Burp Suite et sélectionnez "Temporary Project" (la seule option dans Community Edition). Sur l'écran suivant, sélectionnez "Use Burp defaults" et cliquez sur "Start Burp". L'interface principale se charge avec des onglets en haut : Dashboard, Target, Proxy, Intruder, Repeater et plus. L'onglet Proxy est l'endroit où vous passerez la majorité de votre temps en tant que débutant.

Configurer le proxy du navigateur

Burp Suite fonctionne en interceptant le trafic HTTP entre votre navigateur et l'application cible. Pour cela, vous devez configurer votre navigateur pour router le trafic à travers le listener du proxy de Burp.

Par défaut, Burp écoute sur 127.0.0.1:8080. Vous pouvez vérifier cela dans l'onglet Proxy sous "Proxy settings". Le listener devrait apparaître comme actif.

L'approche la plus simple est d'utiliser le navigateur Chromium intégré de Burp. Cliquez sur "Open browser" dans l'onglet Proxy, et Burp lance un navigateur préconfiguré qui route déjà le trafic à travers le proxy. Cela évite toute configuration du proxy système et isole vos tests de votre navigation habituelle.

Si vous préférez utiliser Firefox, installez l'extension FoxyProxy. Créez une nouvelle entrée proxy avec les paramètres suivants :

• Type de proxy : HTTP
• IP du proxy : 127.0.0.1
• Port : 8080

Activez le proxy dans FoxyProxy, puis naviguez vers http://burpsuite dans Firefox. Cela charge la page de téléchargement du certificat CA de Burp. Téléchargez le certificat, puis importez-le dans Firefox via Paramètres, Vie privée et sécurité, Voir les certificats, Importer. Cette étape est essentielle. Sans le certificat CA installé, les connexions HTTPS afficheront des avertissements de sécurité car Burp effectue une interception man in the middle pour déchiffrer le trafic TLS pour inspection.

Une fois configuré, chaque requête HTTP et HTTPS de votre navigateur passe par Burp Suite. Vous verrez le trafic apparaître dans l'historique HTTP de l'onglet Proxy immédiatement.

Intercepter et modifier les requêtes

L'onglet Proxy est le cœur de Burp Suite. Il a deux modes : interception activée et interception désactivée. Quand l'interception est activée, Burp met en pause chaque requête avant qu'elle n'atteigne le serveur, vous permettant de l'inspecter et de la modifier. Quand l'interception est désactivée, le trafic circule normalement mais reste enregistré dans l'historique HTTP.

Commencez avec l'interception désactivée. Naviguez vers votre instance DVWA dans le navigateur, connectez-vous et parcourez l'application. Passez à l'onglet Proxy et cliquez sur "HTTP history". Vous verrez chaque requête listée avec sa méthode, URL, code de statut, longueur et type MIME. Cliquez sur n'importe quelle requête pour voir les en-têtes et le corps complets dans le panneau inférieur. Cliquez sur l'onglet "Response" pour voir ce que le serveur a renvoyé.

Maintenant activez l'interception. Naviguez vers la page SQL Injection de DVWA et tapez admin dans le champ User ID. Cliquez sur Submit. Au lieu que la page se charge, Burp capture la requête et l'affiche dans l'onglet Intercept. Vous pouvez voir la requête GET ou POST complète, incluant les paramètres, cookies et en-têtes.

C'est là que les tests commencent. Modifiez le paramètre id de admin à 1' OR '1'='1 et cliquez sur "Forward". La requête modifiée atteint le serveur, et la réponse apparaît dans votre navigateur. Si l'application est vulnérable, elle renvoie des données qu'elle ne devrait pas, parce que vous avez altéré la requête que l'application a exécutée contre sa base de données.

GET /vulnerabilities/sqli/?id=1'+OR+'1'%3d'1&Submit=Submit HTTP/1.1
Host: localhost
Cookie: PHPSESSID=abc123; security=low

Cette seule requête modifiée démontre le workflow principal du test de sécurité des applications web : intercepter, analyser, modifier, transmettre, observer. Chaque vulnérabilité que vous trouverez avec Burp suit ce schéma.

Utiliser le Spider et le Crawler

Avant de tester des pages individuelles, vous avez besoin d'une carte de toute l'application. L'onglet Target de Burp construit cette carte pendant que vous naviguez, montrant chaque hôte, répertoire et fichier que l'application référence. Mais la navigation manuelle manque des pages. Le crawler automatise la découverte.

Dans l'onglet Target, faites un clic droit sur votre hôte cible et sélectionnez "Crawl" (dans Community Edition, disponible via l'onglet Dashboard sous "New scan" avec "Crawl" sélectionné). Le crawler suit chaque lien, soumet les formulaires avec des données de test et cartographie la structure de l'application. Il découvre des pages, des paramètres et des endpoints que vous ne trouveriez peut-être jamais manuellement.

Une fois l'exploration terminée, la carte du site dans Target montre l'arborescence complète de l'application. Les répertoires s'étendent pour montrer les fichiers. Chaque fichier montre quels paramètres il accepte. Cette carte devient votre liste de contrôle de test : chaque paramètre est un point d'injection potentiel, chaque formulaire est une surface à sonder.

Passez en revue la carte du site avec un état d'esprit d'attaquant. Cherchez les pages qui acceptent des entrées utilisateur : formulaires de recherche, pages de connexion, champs de commentaires, endpoints de téléchargement de fichiers, paramètres d'URL. Ce sont les emplacements où l'injection SQL, le cross site scripting et d'autres attaques par injection ont le plus de chances de réussir.

Repeater : tests manuels de requêtes

Repeater est l'outil que vous utiliserez le plus après Proxy. Il vous permet d'envoyer une requête au serveur, voir la réponse, modifier la requête et l'envoyer à nouveau, autant de fois que nécessaire. Pas d'interaction avec le navigateur. Juste la requête et la réponse HTTP brutes, côte à côte.

Pour envoyer une requête vers Repeater, faites un clic droit dessus dans l'historique HTTP du Proxy et sélectionnez "Send to Repeater". Passez à l'onglet Repeater. La requête apparaît dans le panneau gauche. Cliquez sur "Send" et la réponse apparaît dans le panneau droit.

Voici comment tester l'injection SQL avec Repeater sur une cible DVWA. Commencez avec la requête capturée depuis la page SQL Injection :

GET /vulnerabilities/sqli/?id=1&Submit=Submit HTTP/1.1
Host: localhost
Cookie: PHPSESSID=abc123; security=low

Modifiez le paramètre id pour envoyer une simple apostrophe : id=1'. Cliquez sur Send. Si la réponse contient un message d'erreur de base de données comme "You have an error in your SQL syntax", le paramètre est injectable. L'application concatène votre entrée directement dans une requête SQL sans assainissement.

Maintenant escaladez. Changez le paramètre en id=1' UNION SELECT user, password FROM users--. Envoyez. Si la réponse inclut des noms d'utilisateur et des hashes de mots de passe de la base de données, vous avez confirmé une injection SQL basée sur UNION qui extrait des données de tables arbitraires.

Repeater excelle dans ces tests itératifs. Chaque modification s'appuie sur la précédente. Vous commencez par une sonde (l'apostrophe), confirmez la vulnérabilité (le message d'erreur), puis escaladez vers l'exploitation complète (la requête UNION). Documentez chaque étape. Votre rapport de pentest doit montrer les requêtes et réponses exactes qui démontrent la vulnérabilité.

Intruder : livraison automatisée de payloads

Intruder automatise le processus d'envoi de nombreuses variations d'une requête, chacune avec un payload différent. Il est essentiel pour les tests de force brute, le fuzzing de paramètres et le scan de vulnérabilités sur plusieurs points d'entrée. Dans Community Edition, Intruder a une limite de débit mais reste fonctionnel pour l'apprentissage.

Pour utiliser Intruder, faites un clic droit sur une requête dans Proxy ou Repeater et sélectionnez "Send to Intruder". L'onglet Intruder a quatre sous-onglets : Positions, Payloads, Settings et Results.

Dans l'onglet Positions, Burp met en évidence les paramètres qu'il pense que vous voulez tester. Effacez toutes les positions avec le bouton "Clear", puis sélectionnez la valeur spécifique que vous voulez tester et cliquez sur "Add". Par exemple, sélectionnez la valeur du paramètre id. Le type d'attaque "Sniper" envoie un payload à la fois à la position marquée, ce qui convient à la plupart des tests.

Passez à l'onglet Payloads. Sous "Payload settings", ajoutez vos chaînes de test. Pour les tests XSS, ajoutez des payloads comme :

<script>alert(1)</script>
<img src=x onerror=alert(1)>
"><script>alert(1)</script>
<svg onload=alert(1)>
'"><img src=x onerror=alert(1)>

Pour l'injection SQL, ajoutez :

' OR '1'='1
' UNION SELECT NULL--
' AND 1=1--
' AND 1=2--
1; DROP TABLE users--

Cliquez sur "Start attack". Intruder envoie chaque payload et affiche les réponses dans un tableau de résultats. Triez par longueur de réponse ou code de statut pour repérer les anomalies. Une réponse significativement plus longue ou plus courte que les autres suggère que le payload a provoqué un comportement différent, ce qui indique souvent une vulnérabilité.

Pour la détection XSS, recherchez vos chaînes de payload dans les corps des réponses. Si <script>alert(1)</script> apparaît non encodé dans la réponse HTML, l'application est vulnérable au cross site scripting réfléchi. Le navigateur exécutera ce script quand une victime visitera l'URL fabriquée.

Trouver XSS et injection SQL dans DVWA

DVWA fournit des vulnérabilités intentionnelles à quatre niveaux de sécurité : low, medium, high et impossible. Commencez à low et montez progressivement. Chaque niveau ajoute une validation d'entrée que vous devez contourner, vous enseignant comment les applications réelles tentent (et échouent) de prévenir les attaques.

Injection SQL au niveau de sécurité low

Naviguez vers la page SQL Injection. Réglez la sécurité DVWA sur "low" dans la page DVWA Security settings. Tapez 1 dans le champ User ID, soumettez et capturez la requête dans Burp. Envoyez-la vers Repeater.

Testez le paramètre id avec : 1' OR '1'='1. La réponse renvoie tous les utilisateurs de la base de données au lieu du seul utilisateur 1. La requête SQL de l'application ressemble à SELECT * FROM users WHERE user_id = '1' OR '1'='1', et puisque '1'='1' est toujours vrai, toutes les lignes sont renvoyées.

Escaladez avec une attaque UNION : 1' UNION SELECT user, password FROM users--. La réponse inclut maintenant les noms d'utilisateur et leurs hashes de mots de passe MD5. C'est un compromis complet de la base de données via un seul champ d'entrée.

XSS réfléchi au niveau de sécurité low

Naviguez vers la page XSS (Reflected). Entrez <script>alert(1)</script> dans le champ de nom et soumettez. La page reflète votre entrée sans encodage, et le script s'exécute. Dans une application réelle, un attaquant fabriquerait une URL contenant ce payload et l'enverrait à une victime. Quand la victime clique sur le lien, le script s'exécute dans sa session de navigateur, pouvant potentiellement voler des cookies, des jetons de session ou des identifiants.

Dans Repeater, testez des variations qui contournent les filtres courants :

<img src=x onerror=alert(document.cookie)>
<svg/onload=alert('XSS')>
<body onload=alert(1)>

Chaque payload réussi démontre un vecteur différent. Le gestionnaire onerror se déclenche quand le navigateur échoue à charger l'image inexistante. Le gestionnaire onload se déclenche quand l'élément SVG est rendu. Comprendre pourquoi chacun fonctionne vous aide à trouver du XSS dans des applications qui filtrent les balises <script> mais manquent les gestionnaires d'événements.

Construire votre workflow de test de sécurité web

Avec Proxy, Repeater et Intruder maîtrisés, vous avez un workflow de test complet. Commencez chaque mission de la même manière :

1. Cartographiez l'application. Naviguez manuellement avec le Proxy capturant le trafic. Lancez le crawler. Passez en revue la carte du site dans Target pour identifier chaque point d'entrée, formulaire, paramètre et endpoint d'API.

2. Identifiez les points d'injection. Chaque paramètre qui accepte une entrée utilisateur est un candidat. Paramètres d'URL, champs de formulaire, en-têtes HTTP (surtout cookies et referrer) et corps de requêtes JSON méritent d'être testés.

3. Testez manuellement avec Repeater. Envoyez des payloads de sondage à chaque point d'injection. Cherchez les messages d'erreur, les comportements inattendus ou les entrées reflétées dans les réponses. Repeater vous donne la précision pour comprendre exactement ce que l'application fait avec votre entrée.

4. Automatisez avec Intruder. Une fois que vous identifiez un paramètre prometteur, utilisez Intruder pour envoyer une liste complète de payloads. Comparez les longueurs de réponse et les codes de statut pour identifier quels payloads ont déclenché des vulnérabilités.

5. Documentez tout. Sauvegardez les requêtes et réponses pour votre rapport. La journalisation intégrée de Burp capture l'échange HTTP complet. Chaque découverte nécessite la requête exacte qui déclenche la vulnérabilité et la réponse qui prouve son existence.

Ce workflow s'applique à chaque application web, d'un simple formulaire de connexion à une API complexe avec des centaines d'endpoints. Les outils s'adaptent à la cible. Votre travail est d'être méthodique, couvrant chaque surface avant de conclure votre test.

Au-delà des bases : PortSwigger Web Security Academy

Une fois à l'aise avec Proxy, Repeater et Intruder dans DVWA, passez à la Web Security Academy de PortSwigger. Elle est gratuite, créée par la même équipe qui développe Burp Suite, et contient plus de 200 labs pratiques couvrant chaque classe majeure de vulnérabilité web. Chaque lab tourne dans un environnement isolé et vous guide à travers la technique d'attaque exacte, de l'injection SQL basique aux attaques avancées de server side request forgery et désérialisation.

L'Academy structure l'apprentissage par type de vulnérabilité. Commencez par les labs d'injection SQL, puis passez au XSS, puis au contournement d'authentification, puis au contrôle d'accès. Chaque section s'appuie sur les concepts de la précédente. Au moment où vous terminerez les labs de niveau apprenti, vous aurez des compétences pratiques directement transférables aux missions réelles.

Associez l'Academy au Guide de test OWASP, qui documente la méthodologie suivie par les pentesters professionnels. Le Guide de test explique quoi tester et pourquoi. L'Academy vous enseigne comment le tester avec Burp Suite. Ensemble, ils construisent à la fois les connaissances et la mémoire musculaire qui séparent les débutants des testeurs efficaces.

Quoi pratiquer ensuite

Le parcours de débutant à testeur compétent d'applications web suit une progression prévisible. Après DVWA, configurez des applications vulnérables supplémentaires : WebGoat pour les vulnérabilités basées sur Java, Juice Shop pour une application monopage moderne, et HackTheBox ou TryHackMe pour des scénarios réalistes. Chaque cible enseigne des schémas de vulnérabilité différents et vous oblige à adapter vos techniques.

Apprenez l'outil Decoder pour encoder et décoder Base64, l'encodage URL, les entités HTML et l'hexadécimal. Beaucoup de payloads nécessitent un encodage pour contourner les pare-feu d'applications web et les filtres d'entrée. Apprenez Comparer pour repérer les différences subtiles entre les réponses qui indiquent un comportement conditionnel, ce qui est la base de l'injection SQL aveugle et des attaques par timing.

Envisagez d'étendre Burp avec des extensions communautaires depuis le BApp Store (onglet Extensions). L'extension "Logger++" ajoute une journalisation améliorée. "Autorize" teste automatiquement les vulnérabilités de contrôle d'accès. "Param Miner" découvre les paramètres cachés. Les extensions multiplient votre efficacité sans nécessiter de construire des outils personnalisés de zéro.

Carla, la pentester qui a trouvé une injection SQL en trente secondes, n'a pas eu de chance. Elle a suivi le même workflow que vous venez d'apprendre : configurer le proxy, intercepter le trafic, tester les paramètres systématiquement et utiliser Repeater pour confirmer et escalader. L'apostrophe était délibérée. L'outil était prêt. La seule variable était la vulnérabilité de l'application. Quand vous suivez ce processus, trouver votre première vraie vulnérabilité n'est pas une question de si. C'est une question de quand.