ZAP, une alternative crédible à BURP Suite ?
Qui, dans le milieu de la sécurité web, n’a jamais entendu parler de ZAP ? Initialement supporté par l’OWASP, Zed Attack Proxy (ZAP) est un outil open-source dédié aux tests de sécurité des applications web. Plus précisément, il s’agit d’un proxy d’interception web qui intègre, parmi d’autres fonctionnalités, un scanner de vulnérabilités passif et actif.
Gratuit et accessible, ZAP est une alternative crédible pour ceux qui n’ont pas accès à Burp Suite Professional, la référence en la matière. Face à la version Community de Burp Suite, qui ne propose pas de scanner de vulnérabilités, ZAP dispose d’atouts solides.
Dans cet article, nous explorerons ZAP à travers la prise en main de son interface. Nous détaillerons également les fonctionnalités clés du proxy (interception, modification et rejeu des requêtes) ainsi que le scanner de vulnérabilités.
Guide complet sur ZAP (Zed Attack Proxy)
ZAP : principes et fonctionnement
Fonctionnement de ZAP
Au démarrage, l’interface de ZAP se présente comme suit :
Avant d’explorer l’interface, commençons par capturer du trafic web. Cela sera plus parlant une fois que nous aurons des données à analyser.
ZAP propose deux modes de fonctionnement :
- Scan automatique : il explore le site et teste ses vulnérabilités à partir d’une simple URL. Cette approche est rapide mais manque de précision et de contrôle. Elle est donc déconseillée..
- Exploration manuelle : ZAP agit comme un proxy entre le navigateur et le serveur. L’auditeur peut observer et manipuler les échanges, puis exécuter des tests ciblés avec les outils intégrés.
ZAP simplifie l’usage en intégrant un navigateur préconfiguré (Chrome ou Firefox). Ainsi, aucun réglage de proxy ou de certificat n’est nécessaire.
Pour commencer, rendez-vous dans « Manual Explore », indiquez l’URL du site à tester puis « Launch Browser ».
Le navigateur s’ouvre et charge le site. Si l’option « Enable HUD » est activée, une interface interactive s’affiche. Vous pouvez la quitter via « Continue to your target ».
NB : Si ZAP affiche l’erreur « the provided browser was not found » ; vous pouvez définir le chemin de votre navigateur via Tools > Options > Selenium > Binaries.
Comprendre l’interface de ZAP
L’interface est divisée en trois zones :
- À gauche (1), nous avons l’arborescence des sites explorés (ici
vaadata-test.local
) et les ressources chargées (CSS, JS, etc.). - En bas (3), on retrouve l’historique des requêtes passées par le proxy. On voit ici la première requête vers la racine du site, puis les requêtes successives vers les différentes ressources. Cette zone peut accueillir d’autres types de données, par l’intermédiaire des différents onglets. Nous les verrons plus tard.
- Au centre (2), nous avons le détail des échanges HTTP. En effet, cette zone affiche les requêtes envoyées et les réponses reçues. Sélectionnez une requête dans le panneau de gauche (1) ou du bas (3) pour voir son contenu dans les onglets « Request » et « Response ». Dans notre exemple, la requête qui s’affiche est celle réalisée par le premier échange (ID 4), sélectionné en bas.
L’interface est personnalisable via la toolbar. En effet, vous pouvez réorganiser les panneaux ou afficher les requêtes/réponses côte à côte pour plus de lisibilité.
À partir de ces 3 volets, on va pouvoir appeler la plupart des fonctionnalités. Pour cela, il faudra s’appuyer sur les différents menus contextuels (clic droit !) qui sont proposés.
Avant de voir les différentes fonctionnalités, notons deux choses vis-à-vis du panel 3.
On y trouve l’onglet « Alerts » qui regroupe les différents éléments découverts par les scanners de ZAP. C’est l’équivalent de issues dans Burp. De plus, il peut contenir plus d’onglets, qui vont s’ouvrir au fur et à mesure de l’utilisation de ZAP.
À noter enfin que ZAP gère également les Websockets. Pour les consulter, un onglet est disponible dans le panel du bas :
Fonctionnalités clés de ZAP
Les différentes fonctionnalités de base que l’on peut attendre d’un proxy d’interception sont présentes dans ZAP. Elles permettent d’intercepter, rejouer ou modifier des requêtes. Il est également possible d’automatiser leur envoi.
Bien que leurs fonctionnalités soient similaires, Burp Suite et ZAP utilisent des terminologies différentes. Pour les utilisateurs habitués à Burp Suite, voici un tableau récapitulant les équivalences :
Dans cette section, nous allons voir comment utiliser Breakpoints, Manual Request Editor, Fuzzer et Active Scanner.
Breakpoints
Les breakpoints permettent d’intercepter (bloquer) les requêtes avant qu’elles ne soient envoyées au serveur; ou les réponses, avant qu’elles ne soient interprétées par le navigateur. Cela permet de les modifier avant de les envoyer, ou d’empêcher leur envoi.
Pour activer les breakpoints de manière globale et intercepter toutes les requêtes, il faut cliquer sur le bouton « break » dans la toolbar :
Une fois activée, les requêtes interceptées vont apparaitre dans l’onglet « Break ».
Il est alors possible de les éditer directement depuis cet onglet, puis d’utiliser les boutons suivants pour transférer (ou bloquer) la requête.
Pour activer un breakpoint spécifique sur un périmètre, cela peut être réalisé à partir du panel Sites, ou via le bouton « Add a custom HTTP breakpoint » dans la toolbar :
Il est alors possible de sélectionner des routes spécifiques, ou des requêtes qui matchent certains critères via une expression régulière :
Manual Request Editor
Pour rejouer une requête, il suffit d’utiliser l’option « Open/Resend with request editor », disponible dans le menu contextuel.
Dans la fenêtre qui s’ouvre, on peut éditer la requête, puis cliquer sur « Send » (ou faire ALT+Entrée) pour renvoyer la requête.
La réponse s’affiche alors directement dans l’onglet réponse :
Fuzzer
Pour envoyer plusieurs requêtes (attaque par dictionnaire ou brute force), l’outil à utiliser s’appelle Fuzzer.
NB : le menu contextuel est parfois différent en fonction de l’endroit où vous cliquez. Par exemple, il est également possible d’invoquer le Fuzzer en cliquant sur le contenu de la requête, puis en sélectionnant directement Fuzz.. Petite astuce donc : si l’action que vous cherchez n’apparaît pas, faites un clic droit sur votre requête à différents endroits (contenu, historique en bas, Sites à gauche).
Dans la fenêtre qui s’ouvre, vous devez à présent sélectionner l’endroit où vous souhaitez injecter vos charges. Pour cela, sélectionnez un endroit dans la requête en positionnant le pointeur ou en surlignant la zone, puis cliquez sur Add.. :
Dans la fenêtre qui s’ouvre, il reste alors à choisir son dictionnaire (vous pouvez par exemple choisir un fichier texte), puis à lancer le Fuzzer :
Les résultats vont alors s’afficher dans le nouvel onglet « Fuzzer » dans l’interface :
Pour des cas un peu plus complexes, il est également possible définir plusieurs points d’entrées différents (dans ce cas, toutes les combinaisons vont être envoyées), et de modifier les payloads avant de les envoyer (encodage, ajout de préfixe/suffixe, etc.).
Active Scanner
L’avantage de ZAP par rapport à la version Community de Burp, c’est qu’il possède un scanner de vulnérabilités.
Le scanner passif est activé par défaut. Il analyse le trafic en continu et crée des alertes lorsque des éléments suspects sont détectés.
Le scanner actif peut être déclenché par l’utilisateur de plusieurs manières :
- Soit en activant le mode Attack (Live scan) : le scanner va automatiquement scanner toutes les URLs qui vont apparaître dans le scope. Pour rappel, nous ne recommandons pas cette approche, car elle risque d’endommager la plateforme.
- Soit en sélectionnant une requête spécifique, et en choisissant Attack > Active Scan…
Une fois la fonctionnalité ouverte, il est possible de scanner l’intégralité de la requête, ou de spécifier le paramètre/champ/emplacement que l’on souhaite scanner.
Le premier cas est le comportement par défaut, il suffit donc de démarrer le scanner en cliquant sur « Start Scanner ».
Dans le second cas, il faut se rendre dans l’onglet Custom Vectors, sélectionner un champ en le surlignant (ou un espace vide) puis cliquer sur Add. Cochez également l’option « Disable Non-custom Input Vectors » pour que le scanner ne s’applique qu’au(x) champ(s) sélectionné(s).
Lorsque le scan démarre, l’onglet Active Scan s’ouvre et affiche toutes les requêtes émises par le scanner. En sélectionnant l’une d’elles, on constate que les payloads sont bien envoyées uniquement dans le champ demandé :
Les résultats sont ensuite affichés dans l’onglet Alerts :
Bingo ! Le scanner a découvert (entre autres) une injection SQL. Mieux encore, il a été capable de déterminer une payload UNION qui peut être utilisée pour extraire des données de la base.
Spidering
Le spidering permet de parcourir l’arborescence d’une application, de manière à découvrir un maximum de routes/paramètres existant.
Pour lancer le spidering « classique » (crawling du site web à partir des liens apparents dans les différentes pages) sur un site, il suffit de sélectionner la cible dans le menu Sites, puis choisir Attack > Spider…
Par défaut, les formulaires sont soumis par l’outil, ce qui peut avoir un impact sur la plateforme. Pour désactiver cette option, il faut cocher l’option « Show Advanced Options », puis dans l’onglet Advanced, décocher les options « Process Forms » et « POST Forms » :
Les requêtes envoyées par le spidering sont alors visibles dans l’onglet Spider, et l’arborescence du site est également mise à jour en fonction des pages visitées dans le panel latéral Sites :
Ce type de spidering est particulièrement rapide (quelques secondes sur notre site de test).
ZAP dispose également d’un autre type de spidering appelé « AJAX Spider ». Celui-ci fonctionne sur une approche différente : les URLs connues sont ouvertes dans un navigateur web, de manière à ce que le code JavaScript puisse être exécuté, et que les requêtes AJAX (s’il y en a) puissent permettre de charger des données. Le DOM est ensuite analysé par ZAP, de manière à en extraire les URLs qui pourraient s’y trouver.
Ce type de spidering est beaucoup plus long, car il repose sur l’ouverture de navigateurs et l’interprétation du code, mais peut s’avérer efficace pour les applications modernes qui s’appuient sur un front JavaScript et des requêtes AJAX au backend.
Enfin, le « Client Spider » est une nouveauté de la version 2.16 de ZAP (janvier 2025). Il a pour vocation, à terme, de remplacer l’AJAX Spider, qui s’appuie sur une technologie externe à ZAP.
Extensions Zap
ZAP dispose d’une Marketplace qui permet simplement d’ajouter des extensions à l’outil.
Vous pouvez ouvrir la marketplace en cliquant sur le bouton « Manage Add-ons » dans la toolbar :
Dans cette marketplace, on trouve des extensions très diverses : ajout de tests dans le scanner, ajout d’options dans les différentes fonctionnalités, ajout d’un package de langue, ajouts d’effets visuels pour améliorer l’interface, etc.
Pour installer une extension, il suffit de la sélectionner dans la marketplace, puis de cliquer sur « Install Selected » :
Quelques extensions que nous pouvons recommander : Active scanner rules, Passive scanner rules et Community scripts.
Limites et scripting
Nous avons vu que ZAP dispose des fonctionnalités nécessaires dans un proxy d’interception web, parfaitement fonctionnelles dans des cas d’utilisation relativement simples.
Cependant, dès que l’on s’écarte de ces cas simples, on constate que l’on est assez vite limité par les fonctionnalités proposées nativement par l’outil.
Deux exemples couramment rencontrés lors d’un audit :
- Pas de fonctionnalités de type « Match and Replace » permettant d’automatiser la modification des requêtes et/ou des réponses en fonction de patterns sélectionnés.
- Le chaînage de requêtes, comme on pourrait le faire sur BURP avec des Macros ou avec l’extension Stepper, ce qui est indispensable dans des cas de workflows multi-steps.
Pour pallier ces manques de fonctionnalités, ZAP s’appuie sur un système de scripts qui s’avère assez fastidieux en pratique.
Ces Scripts peuvent être affichés en ouvrant l’onglet Scripts à côté de Sites (cliquer sur « + ») :
Pour avoir un maximum de scripts disponibles, il est recommandé d’installer les extensions suivantes disponibles dans le Marketplace :
Les scripts proposés sont assez divers et variés et s’appliquent de manière différente en fonction de leur nature.
Scripts Stand Alone
On trouve des scripts Stand Alone qui s’appliquent de manière ponctuelle, dans l’environnement général de ZAP.
Par exemple, le script Loop through history table.py va parcourir l’historique du projet et imprimer toutes les routes qui ont été visitées.
Scripts Targeted
D’autres types de scripts (Targeted) s’appliquent plus spécifiquement sur une requête/réponse sélectionnée par l’utilisateur à partir du menu contextuel « Invoke with Script ».
L’action du script est alors réalisée uniquement sur l’échange sélectionné. Par exemple : extraire les commentaires présents dans une page :
Autres scripts
Certains scripts vont être automatiquement déclenchés pour chaque requêtes/réponses : le code du script pourra donc contenir des contrôles afin de déterminer dans quels cas celui-ci doit réaliser une action sur la requête ou la réponse.
Prenons le cas cité précédemment du « Match and Replace » :
Une fois le script démarré, on constate que la modification est bien réalisée automatiquement sur les requêtes concernées (le paramètre Submit=Connexion est remplacé par Submit=Register).
En résumé les scripts permettent d’ajouter une souplesse lorsque les fonctionnalités natives de ZAP s’avèrent limitées. L’utilisateur est assez libre dans le développement de scripts (plusieurs langages possibles), et la communauté met à disposition (via la marketplace) des scripts utiles pour réaliser des actions relativement courantes.
Cependant, l’utilisation de scripts s’avère fastidieuse (duplication d’un même script lorsque plusieurs « Match and Replace » sont nécessaires) là où une simple fonctionnalité pourrait faire l’affaire.
De plus, l’exécution des scripts n’est pas très claire au niveau de l’interface (dans l’exemple précédent, la requête est bien modifiée, mais rien ne l’indique). Surtout, cela se limite à nouveau à des cas simples (modifications ponctuelles par exemple), mais ne semble pas être suffisant dans les cas d’applications complexes (macro, Stepper, AuthAnalyzer).
Le HUD de ZAP : une interface graphique directement dans le navigateur
ZAP propose une seconde interface graphique, directement intégrée au navigateur de l’utilisateur.
Ce HUD (Heads-Up Display) est un véritable atout, permettant d’exécuter des actions sans avoir à jongler entre le navigateur et le proxy. Une fonctionnalité unique que Burp ne propose pas.
Pour activer le HUD, il suffit de cocher « Enable HUD » lors du lancement du navigateur via ZAP ou de cliquer sur « Enable the ZAP HUD » dans la barre d’outils.
Une fois activée, l’interface est automatiquement ajoutée au navigateur. Vous devriez voir la page d’accueil suivante :
Pour afficher le tutoriel du HUD, cliquez sur le bouton de gauche. Sinon, sélectionnez « Continue to your target » pour accéder directement au site à tester.
L’avantage majeur de cette interface est qu’elle permet d’accéder aux informations de ZAP sans quitter le navigateur. Vous pouvez consulter l’historique des requêtes et des WebSockets, voir les alertes du scanner, et exécuter des actions comme le scanner, le spidering ou les breakpoints, le tout sans avoir à basculer entre plusieurs fenêtres.
En cliquant sur une requête dans l’historique, on peut voir les détails de la requête et, par exemple, choisir de la modifier et de la renvoyer ou de lancer un scanner actif.
On peut également afficher les alertes qui sont relevées par ZAP (et qui apparaissent en temps réel dans le HUD via des notifications) :
Conclusion
ZAP est bien équipé pour les usages classiques d’un proxy web : observer, intercepter et générer du trafic HTTP, que ce soit manuellement ou de façon automatisée. Il intègre également un scanner actif performant, utilisable avec précision. Son HUD est un atout notable, offrant plus de confort et facilitant la prise en main pour les novices qui ne maîtrisent pas encore l’interface standard.
Comparé à la version Community de Burp Suite, ZAP se démarque. Burp ne propose ni scanner de vulnérabilités, ni sauvegarde de projet, et impose des restrictions sur certaines fonctionnalités, comme Intruder.
ZAP reste toutefois limité pour un usage professionnel. Il est plutôt adapté à des besoins ponctuels : tester son propre site web, participer à des CTF et autres challenges Web, etc.
Auteur : Cédric CALLY-CABALLERO – Pentester @Vaadata