Aller au contenu

TP : DAST avec OWASP ZAP Proxy

Ce TP vous fait manipuler OWASP ZAP sur une application web volontairement vulnérable, d'abord en local puis dans une pipeline GitLab CI/CD

L'objectif est de vous entraîner sur des usages concrets de ZAP sans partir de zéro sur l'application cible

Objectifs du TP

  • Utiliser ZAP comme proxy local pour observer et intercepter le trafic HTTP
  • Réaliser un scan passif de type Baseline sur une application web existante
  • Réaliser un scan actif sur un environnement dédié
  • Générer et lire un rapport HTML de scan
  • Intégrer un scan ZAP dans une pipeline GitLab CI/CD
  • Ajuster le comportement du scan avec un fichier de configuration

Pré-requis

  • Docker installé et fonctionnel
  • OWASP ZAP Desktop installé en local
  • Un dépôt GitLab avec un fichier .gitlab-ci.yml
  • Une application web volontairement vulnérable accessible en HTTP ou HTTPS
  • Un navigateur web

Applications cibles recommandées

Pour éviter de perdre du temps à créer une application vulnérable, utilisez une cible existante

Option 1 : OWASP Juice Shop

Recommandé pour un TP ZAP complet

  • application moderne
  • beaucoup de surface fonctionnelle
  • adaptée au proxy, au baseline scan et au full scan

Exemple de lancement en local :

docker run -d --name juice-shop -p 3000:3000 bkimminich/juice-shop

URL cible :

http://localhost:3000

Option 2 : OWASP WebGoat

Recommandé si vous voulez relier plus facilement les exercices à des familles de vulnérabilités connues

  • approche très pédagogique
  • environnement de formation reconnu
  • intéressant pour l'entraînement manuel avec proxy

Option 3 : OWASP PyGoat

Recommandé si vous travaillez déjà avec Python et Django

  • bon support pour discuter des vulnérabilités applicatives
  • utile si vous voulez faire le lien entre scan dynamique et code source

Option 4 : Une application vulnérable déjà utilisée dans vos autres TP

Cette option est pertinente si vous avez déjà :

  • une application déployable en local
  • un dépôt GitLab existant
  • une pipeline CI/CD que vous pouvez enrichir

Dans tous les cas, privilégiez une cible :

  • simple à lancer
  • accessible depuis Docker
  • isolée du reste du système
  • réservée à un usage pédagogique

Partie 1 : Prise en main de ZAP en local

Exercice 1 : Démarrer l'application cible

  1. Lancez OWASP Juice Shop en local avec Docker
  2. Vérifiez que l'application répond dans le navigateur
  3. Identifiez rapidement les principales routes ou écrans visibles sans authentification
  4. Notez quelles actions utilisateur génèrent des appels réseau intéressants

Exercice 2 : Lancer ZAP Desktop

Lancez l'application OWASP ZAP Desktop installée sur votre machine

Sur macOS, ouvrez l'application depuis le dossier Applications

Sur Windows, ouvrez l'application depuis le menu Démarrer ou le raccourci installé

  1. Ouvrez l'interface desktop de ZAP
  2. Repérez les zones suivantes :
  3. l'arbre des sites
  4. l'historique des requêtes
  5. les alertes
  6. les détails requête/réponse
  7. Si vous voulez intercepter du HTTPS, exportez le certificat racine de ZAP depuis l'interface puis importez-le dans votre navigateur de test

Exercice 3 : Utiliser ZAP comme proxy d'interception

  1. Configurez votre navigateur pour utiliser localhost:8080 comme proxy HTTP
  2. Naviguez sur l'application cible
  3. Vérifiez que les requêtes apparaissent dans ZAP
  4. Activez le mode interception
  5. Rejouez une action simple sur l'application
  6. Modifiez une valeur dans une requête avant de la transmettre
  7. Observez l'effet côté application et côté réponse HTTP

Exemples d'actions intéressantes :

  • formulaire de connexion
  • recherche de produit
  • ajout au panier
  • modification de paramètres dans l'URL

Partie 2 : Scan passif et lecture des alertes

Exercice 4 : Réaliser un Baseline Scan

Le scan Baseline est un scan passif adapté à la CI/CD. Il explore la cible et analyse les réponses sans tenter d'exploitation active

Depuis un terminal, lancez :

docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t http://host.docker.internal:3000 \
  -r zap-baseline-report.html \
  -J zap-baseline-report.json

Si host.docker.internal ne fonctionne pas sur votre machine, adaptez la cible pour qu'elle soit joignable depuis le conteneur ZAP

Travail demandé :

  1. Exécutez le scan baseline
  2. Ouvrez le rapport HTML généré
  3. Repérez au moins trois alertes remontées par ZAP
  4. Classez-les entre :
  5. défauts d'en-têtes de sécurité
  6. exposition d'informations
  7. comportements applicatifs faibles
  8. Identifiez quelles alertes semblent faciles à corriger et lesquelles demanderaient une modification applicative

Exercice 5 : Ajuster le scan avec un fichier de configuration

Générez un fichier de configuration de référence :

docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t http://host.docker.internal:3000 \
  -g zap-baseline.conf
  1. Ouvrez le fichier généré
  2. Choisissez une ou deux règles à passer en IGNORE
  3. Choisissez une ou deux règles à passer en FAIL
  4. Relancez le scan avec l'option -c
  5. Comparez le résultat avec le premier rapport
  6. Expliquez dans quels cas il est légitime d'ignorer une alerte

Partie 3 : Scan actif sur environnement dédié

Exercice 6 : Réaliser un Full Scan

Le full scan lance aussi des attaques actives. Il ne doit pas être exécuté sur une production

Commande de départ :

docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t http://host.docker.internal:3000 \
  -r zap-full-report.html \
  -J zap-full-report.json \
  -m 3

Travail demandé :

  1. Exécutez ce scan uniquement sur votre environnement local ou un environnement de test
  2. Comparez le temps d'exécution avec le baseline scan
  3. Comparez le nombre et la criticité des alertes
  4. Repérez les alertes qui n'apparaissaient pas dans le scan passif
  5. Identifiez une action applicative potentiellement risquée déclenchée pendant le scan

Partie 4 : Intégration GitLab CI/CD

Exercice 7 : Ajouter un job de baseline scan

Ajoutez un stage security_scan puis créez un job de scan ZAP

Base de travail :

stages:
  - security_scan

zap_baseline_scan:
  stage: security_scan
  image: ghcr.io/zaproxy/zaproxy:stable
  variables:
    TARGET_URL: "http://example.com"
  script:
    - mkdir -p /zap/wrk
    - zap-baseline.py -t "$TARGET_URL" -r zap-report.html -J zap-report.json
  artifacts:
    when: always
    paths:
      - zap-report.html
      - zap-report.json

Travail demandé :

  1. Adaptez TARGET_URL à votre application vulnérable déjà déployée sur un environnement de test ou de staging
  2. Exécutez le pipeline
  3. Téléchargez et lisez les artifacts générés
  4. Vérifiez si le job bloque ou non le pipeline selon les alertes rencontrées

Exercice 8 : Faire évoluer la politique de sécurité

  1. Générez un fichier de configuration ZAP depuis la ligne de commande
  2. Versionnez ce fichier dans votre dépôt
  3. Modifiez le job GitLab pour utiliser ce fichier via l'option -c
  4. Faites en sorte qu'au moins une alerte importante provoque un échec du job
  5. Faites ensuite évoluer la configuration pour réduire les faux positifs ou les alertes non prioritaires

Exercice 9 : Préparer un full scan planifié

Ajoutez un second job, distinct du baseline scan, destiné à un scan plus lourd

Contraintes :

  • il doit utiliser zap-full-scan.py
  • il ne doit tourner qu'en manual
  • il doit cibler uniquement un environnement dédié (Cf: example.com ou app en Gitlab Services)

Travail demandé :

  1. Créez ce second job
  2. Définissez une stratégie d'exécution
  3. Générez un rapport HTML distinct
  4. Expliquez pourquoi ce job ne doit pas être déclenché sur un environnement partagé sans précaution

☕️ Si tu souhaites soutenir mon travail, tu peux m'offrir un café ici.