Aller au contenu principal

OWASP ZAP

L'art de scanner le web comme un hacker... légalement

Notions théoriques​

Imaginez que vous venez de passer des semaines à développer une application Web. Elle est belle, rapide, fonctionnelle.

Mais votre application Web est-elle sécurisée ? La plupart du temps, on ne le sait pas, jusqu'à ce qu'un attaquant le découvre avant nous et exploite la faille pour voler des données, injecter du code malveillant, ou prendre le contrôle du serveur.

C'est exactement là qu'intervient OWASP ZAP.

Qu'est-ce qu'OWASP ?​

L'OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif dont la mission est d'améliorer la sécurité des logiciels. Elle est connue notamment pour son célèbre classement OWASP Top 10, qui recense les dix vulnérabilités web les plus critiques (injections SQL, failles XSS, mauvaises configurations, etc.). Ce référentiel est utilisé par des entreprises du monde entier pour auditer leurs applications.

Qu'est-ce qu'OWASP ZAP ?​

ZAP (Zed Attack Proxy) est un outil open source de test de sécurité développé et maintenu par l'OWASP. Il fonctionne comme un proxy intercepteur : il se place entre votre navigateur et le serveur web que vous testez, et analyse tout le trafic HTTP qui passe par lui.

ZAP permet de :

  • Scanner automatiquement une application web à la recherche de vulnérabilités connues
  • Intercepter et modifier des requêtes HTTP en temps réel
  • Rejouer des attaques manuellement pour tester des failles spécifiques
  • Générer des rapports détaillés sur les vulnérabilités détectées

Comment fonctionne un proxy intercepteur ?​

Normalement, quand vous tapez une URL dans votre navigateur, la requête va directement au serveur. Avec ZAP configuré comme proxy, la requête passe d'abord par ZAP, qui peut la lire, la modifier, l'enregistrer, puis la transmettre. La réponse du serveur revient également via ZAP avant d'atteindre votre navigateur.

[Navigateur] --> [ZAP (proxy)] --> [Serveur web]
[Navigateur] <-- [ZAP (proxy)] <-- [Serveur web]

ZAP écoute par défaut sur localhost:8080.

Les 2 modes principaux de ZAP​

1. Le scan passif

En mode passif, ZAP analyse le trafic que vous générez en naviguant normalement sur le site. Il ne génère aucune requête supplémentaire, mais signale les problèmes visibles dans les échanges : cookies sans flag HttpOnly, en-têtes de sécurité manquants (Content-Security-Policy, X-Frame-Options...), informations sensibles exposées, etc.

Ce mode est non intrusif et peut être utilisé sur des environnements de production (avec précaution).

2. Le scan actif

Le scan actif est autrement plus agressif : ZAP génère des milliers de requêtes automatiques pour tenter d'exploiter des failles. Il teste les injections SQL, les failles XSS (Cross-Site Scripting), les traversées de répertoires, les inclusions de fichiers distants, et bien d'autres vulnérabilités issues du Top 10 OWASP.

Ce mode doit être utilisé uniquement sur des environnements que vous possédez ou pour lesquels vous avez une autorisation écrite. L'utiliser sans autorisation sur un site tiers constitue une infraction pénale.

Les alertes ZAP​

Après un scan, ZAP classe ses découvertes par niveau de risque :

NiveauCouleurExemple
HighRougeInjection SQL détectée
MediumOrangeEn-tête X-Frame-Options absent
LowJauneCookie sans attribut Secure
InformationalBleuTechnologie détectée (Apache, PHP...)

Chaque alerte est accompagnée d'une description, d'une preuve (la requête incriminée), et d'une recommandation de correction.

Pourquoi ZAP est indispensable pour un développeur web ?​

Un développeur web n'est pas un expert en cybersécurité... mais il a la responsabilité du code qu'il produit. OWASP ZAP permet de tester soi-même sa propre application avant de la déployer en production, d'intégrer des tests de sécurité dans une pipeline CI/CD, et de comprendre concrètement comment fonctionnent les attaques courantes.

ZAP est disponible en interface graphique (idéale pour débuter) et en ligne de commande (pour l'automatisation). Il est gratuit, multiplateforme (Windows, Linux, macOS) et activement maintenu.

Exemple pratique​

Contexte​

Pour pratiquer légalement, nous allons utiliser DVWA (Damn Vulnerable Web Application), une application volontairement vulnérable conçue pour l'apprentissage.

l'application Web DVWA peut être facilement installée en local via Docker :

docker run --rm -it -p 80:80 vulnerables/web-dvwa

Accédez ensuite à http://localhost dans votre navigateur (identifiants par défaut : admin / password).

Étape 1 — Lancer ZAP et configurer le proxy​

  1. Téléchargez ZAP depuis zaproxy.org et installez-le.
  2. Au lancement, choisissez "Persisted Session" pour conserver vos résultats.
  3. ZAP écoute par défaut sur 127.0.0.1:8080. Configurez votre navigateur pour utiliser ce proxy.

Sous Firefox : Paramètres > Réseau > Paramètres de connexion > Proxy manuel : 127.0.0.1, port 8080.

Étape 2 — Naviguer sur DVWA pour alimenter le scan passif​

Naviguez sur quelques pages de DVWA (formulaire de login, pages de l'application). ZAP enregistre toutes les URLs visitées dans l'arborescence "Sites" visible dans le panneau de gauche. C'est la phase de découverte (spider manuel).

Étape 3 — Lancer le Spider automatique​

Faites un clic droit sur http://localhost dans le panneau "Sites" > "Attack" > "Spider". ZAP va automatiquement explorer toutes les pages liées à cette URL, simulant un robot d'indexation.

Étape 4 — Lancer le scan actif​

Une fois le spider terminé, faites un clic droit sur http://localhost > "Attack" > "Active Scan". ZAP va désormais bombarder chaque paramètre détecté avec des payloads d'attaque.

Étape 5 — Analyser les alertes​

Cliquez sur l'onglet "Alerts" en bas de l'interface. Vous verrez apparaître des alertes de niveau High (rouge), notamment des injections SQL et des failles XSS — car DVWA en est truffée par conception.

Cliquez sur une alerte pour voir :

  • La requête exacte envoyée par ZAP
  • La réponse du serveur qui trahit la vulnérabilité
  • La recommandation de correction

Étape 6 — Générer un rapport​

Allez dans "Report" > "Generate HTML Report".

Vous obtenez un fichier HTML complet et imprimable, listant toutes les vulnérabilités par niveau de criticité.

astuce

Ce rapport est très utile pour une présentation client ou une revue de code sécurité.

Test de mémorisation/compréhension​


Que signifie l'acronyme ZAP dans OWASP ZAP ?


Sur quel port ZAP écoute-t-il par défaut en tant que proxy ?


Quelle est la différence fondamentale entre le scan passif et le scan actif dans ZAP ?


Quel niveau d'alerte ZAP correspond à la couleur rouge ?


Qu'est-ce que DVWA ?


À quoi sert le 'Spider' dans ZAP ?


L'OWASP Top 10 est...


Que se passe-t-il lorsque vous configurez ZAP comme proxy dans votre navigateur ?


Utiliser le scan actif de ZAP sur un site sans autorisation est...


Quel en-tête HTTP manquant peut être signalé par ZAP comme une alerte de niveau Medium ?


TP 1 — Audit de sécurité de OWASP Juice Shop

OWASP Juice Shop est une application Web e-commerce volontairement truffée de vulnérabilités. Contrairement à DVWA, elle ressemble à une vraie application moderne : interface React, API REST, base de données SQLite, authentification JWT.

astuce

OWASP Juice Shop est un terrain d'entraînement bien plus réaliste que la plupart des environnements de test. Dans ce TP, vous allez utiliser ZAP pour identifier ses failles, comprendre leur mécanisme, et proposer des corrections.

Partie 1 — Mise en place de l'environnement​

Étape 1.1 — Lancer Juice Shop via Docker​

Ouvrez un terminal et exécutez la commande suivante :

docker pull bkimminich/juice-shop
docker run --rm -p 3000:3000 bkimminich/juice-shop

Attendez que le terminal affiche une ligne indiquant que le serveur écoute sur le port 3000. Ouvrez ensuite votre navigateur et accédez à :

http://localhost:3000

Vous devez voir apparaître la boutique en ligne Juice Shop avec ses produits.

Si Docker n'est pas installé sur votre machine, téléchargez-le depuis https://www.docker.com/products/docker-desktop

Une solution

Étape 1.2 — Configurer ZAP comme proxy​

Lancez OWASP ZAP. Au démarrage, choisissez "Persisted Session" et donnez-lui un nom (ex : juice-shop-audit).

Vérifiez que ZAP écoute bien sur 127.0.0.1:8080 en allant dans : Tools > Options > Network > Local Servers/Proxies

Configurez ensuite votre navigateur Firefox pour passer par ce proxy :

  • Allez dans Paramètres > Général > Réseau > Paramètres de connexion
  • Sélectionnez "Configuration manuelle du proxy"
  • Adresse HTTP : 127.0.0.1, Port : 8080
  • Cochez "Utiliser ce proxy pour tous les protocoles"

Accédez à http://localhost:3000 depuis Firefox. L'URL doit apparaître dans le panneau "Sites" de ZAP à gauche.

Une solution

Partie 2 — Exploration manuelle et découverte passive​

Étape 2.1 — Naviguer sur l'application pour alimenter ZAP​

Sans lancer aucun scan pour l'instant, naviguez manuellement sur Juice Shop pendant environ 5 minutes. Effectuez les actions suivantes dans Firefox :

  1. Parcourez la liste des produits (page d'accueil)
  2. Cliquez sur plusieurs produits pour voir leur fiche détaillée
  3. Créez un compte via le formulaire d'inscription (#/register)
  4. Connectez-vous avec votre nouveau compte
  5. Ajoutez un produit au panier
  6. Consultez la page "About Us" et la page de contact

Ne cherchez pas encore à trouver des failles : l'objectif ici est de laisser ZAP cartographier l'application au fil de votre navigation.

Une solution

Étape 2.2 — Analyser les alertes du scan passif​

Dans ZAP, cliquez sur l'onglet "Alerts" en bas de l'interface. Des alertes ont déjà été générées par le scan passif, uniquement en observant le trafic de votre navigation.

Répondez aux questions suivantes dans un fichier texte :

  1. Combien d'alertes passives ont été détectées au total ?
  2. Y a-t-il des alertes de niveau "Medium" ou "High" ? Si oui, lesquelles ?
  3. Repérez l'alerte intitulée "Content Security Policy (CSP) Header Not Set" : que signifie-t-elle concrètement ?
Une solution

Partie 3 — Spider et scan actif​

Étape 3.1 — Lancer le Spider AJAX​

Juice Shop est une application Angular (SPA). Le Spider classique de ZAP, conçu pour les sites multi-pages traditionnels, ne sera pas très efficace ici car la navigation se fait principalement en JavaScript. Il faut utiliser le Spider AJAX, qui pilote un vrai navigateur.

Dans ZAP :

  1. Faites un clic droit sur http://localhost:3000 dans le panneau "Sites"
  2. Sélectionnez "Attack" > "Ajax Spider"
  3. Dans la fenêtre qui s'ouvre, choisissez le navigateur "Firefox Headless"
  4. Cliquez sur "Start Scan"

Attendez la fin du spider (environ 2 à 3 minutes). Observez l'onglet "Ajax Spider" qui s'affiche en bas : vous voyez le nombre d'URLs découvertes augmenter progressivement.

Une solution

Étape 3.2 — Lancer le scan actif​

Une fois le Spider AJAX terminé :

  1. Faites un clic droit sur http://localhost:3000 dans le panneau "Sites"
  2. Sélectionnez "Attack" > "Active Scan"
  3. Dans la fenêtre de configuration, laissez les paramètres par défaut
  4. Cliquez sur "Start Scan"

Le scan actif prend entre 5 et 15 minutes selon votre machine. Pendant ce temps, observez l'onglet "Active Scan" en bas : vous voyez défiler les requêtes que ZAP envoie automatiquement, ainsi que le pourcentage de progression.

Ne fermez pas ZAP et n'arrêtez pas le conteneur Docker pendant cette étape.

Une solution

Partie 4 — Analyse des vulnérabilités détectées​

Étape 4.1 — Identifier et documenter les alertes critiques​

Une fois le scan actif terminé, allez dans l'onglet "Alerts". Filtrez par niveau "High" (rouge).

Pour chacune des alertes High trouvées, documentez dans un fichier texte :

  • Le nom de la vulnérabilité
  • L'URL concernée
  • Le paramètre vulnérable
  • La requête exacte envoyée par ZAP (visible dans le panneau de droite en cliquant sur l'alerte)
  • La réponse du serveur qui confirme la vulnérabilité

Concentrez-vous en priorité sur les alertes liées aux injections SQL et aux XSS.

Une solution

Étape 4.2 — Exploiter manuellement l'injection SQL​

Cette étape se fait directement dans le navigateur, sans ZAP, pour comprendre concrètement ce que permet la vulnérabilité.

Accédez à l'URL suivante dans Firefox :

http://localhost:3000/rest/products/search?q='))--

Observez la réponse JSON retournée par le serveur. Que contient-elle ? Comparez avec une requête normale :

http://localhost:3000/rest/products/search?q=apple

Maintenant, tentez d'extraire des informations sur la structure de la base de données en utilisant une injection UNION :

http://localhost:3000/rest/products/search?q=')) UNION SELECT id, email, password, '4', '5', '6', '7', '8', '9' FROM Users--

Notez ce que vous obtenez dans la réponse et réfléchissez aux conséquences pour les utilisateurs de cette application.

Une solution

Étape 4.3 — Tester le contournement d'authentification​

Juice Shop possède une faille classique sur son formulaire de connexion. Accédez à http://localhost:3000/#/login.

Sans créer de compte administrateur, tentez de vous connecter en tant qu'administrateur en utilisant l'injection SQL suivante dans le champ email :

' OR 1=1--

Et n'importe quelle valeur dans le champ mot de passe (ex : anything).

Observez ce qui se passe. Quel compte est connecté ? Comment expliquer ce comportement ?

Dans ZAP, retrouvez la requête POST correspondante dans l'onglet "History" et examinez le corps de la requête ainsi que la réponse du serveur.

Une solution

Partie 5 — Génération du rapport et recommandations​

Étape 5.1 — Générer le rapport HTML​

Dans ZAP, allez dans Report > Generate Report.

Choisissez le format HTML et sélectionnez un répertoire de destination. Nommez le fichier rapport-juiceshop.html.

Ouvrez ce fichier dans votre navigateur et vérifiez qu'il contient :

  • Un résumé avec le nombre d'alertes par niveau de risque
  • La liste détaillée de chaque vulnérabilité
  • Pour chaque vulnérabilité : la description, la preuve (requête/réponse), et les recommandations de correction
Une solution

Étape 5.2 — Rédiger le plan de remédiation​

Sur la base de vos découvertes, rédigez un court plan de remédiation (15 à 20 lignes) destiné à l'équipe de développement. Ce document doit :

  1. Lister les 3 vulnérabilités les plus critiques trouvées, par ordre de priorité
  2. Pour chacune, expliquer le risque en termes métier (pas uniquement technique)
  3. Proposer une correction précise avec un exemple de code si possible
  4. Évaluer grossièrement la difficulté de correction (facile / modérée / complexe)

Ce document ne doit pas dépasser une page A4.

Une solution

Récapitulatif de ce que vous avez accompli​

Au terme de ce TP, vous avez configuré un environnement de test réaliste avec une application Web moderne, utilisé le Spider AJAX pour cartographier une SPA Angular, lancé et interprété un scan actif ZAP, exploité manuellement une injection SQL pour en mesurer l'impact réel, contourné un système d'authentification par injection SQL, et produit un rapport d'audit exploitable avec un plan de remédiation structuré.

Ce sont exactement les étapes suivies par un auditeur en sécurité applicative lors d'un test de pénétration (pentest) Web en conditions réelles, dans le cadre d'une mission autorisée par le client.

TP 2 — Audit de sécurité de DVWA​

Contexte du TP​

Vous êtes développeur web junior dans une startup, et votre chef de projet vous demande d'effectuer un audit de sécurité de base sur l'application interne de test avant la mise en production. Pour cela, vous disposez de DVWA en local et de ZAP.

Travail demandé​

Partie 1 — Mise en place

  1. Lancez DVWA via Docker : 
    docker run --rm -it -p 80:80 vulnerables/web-dvwa
  2. Connectez-vous à http://localhost avec admin / password.
  3. Cliquez sur le bouton "Create database" (si cela n'a pas déjà été fait)
  4. Reconnectez-vous à http://localhost avec admin / password.
  5. Dans DVWA, allez dans "DVWA Security" et vérifiez que le niveau de sécurité est bien "Low" (sinon le mettre à "Low").
  6. Lancez "OWASP ZAP" (si besoin, consultez le TP n°1)
  7. Configurez votre navigateur pour passer par le proxy 127.0.0.1:8080.

Partie 2 — Exploration et scan

  1. Naviguez manuellement sur au moins 5 pages différentes de DVWA (le formulaire de login, la page SQL Injection, la page XSS Reflected, etc.) pour alimenter ZAP en données.
  2. Lancez le Spider sur http://localhost depuis ZAP et attendez qu'il se termine.
  3. Lancez ensuite le scan actif sur http://localhost.

Partie 3 — Analyse et rapport

  1. Une fois le scan terminé, listez dans un fichier texte ou une capture d'écran :
    • Le nombre total d'alertes détectées
    • Le nombre d'alertes de niveau High (rouge)
    • Le nom d'au moins deux alertes de niveau High avec leur description
  2. Pour l'une des alertes High, identifiez :
    • La requête envoyée par ZAP qui a déclenché l'alerte
    • La correction recommandée par ZAP
  3. Générez un rapport HTML via ZAP (Report > Generate HTML Report) et ouvrez-le dans votre navigateur. Vérifiez qu'il contient bien un résumé des vulnérabilités.

Question de réflexion

En vous appuyant sur les alertes trouvées, répondez en quelques lignes : si cette application était réellement en production avec ces vulnérabilités, quelle serait la première faille à corriger en priorité, et pourquoi ?

Une solution