🛡️ Synthèse des Failles Web & Contre-Mesures
1. SQL Injection (Basic)
Description : L'injection SQL permet à un attaquant d'injecter des requêtes malveillantes via des champs non filtrés (ex : ' OR 1=1 --).
Contre-mesures :
- Utiliser des requêtes préparées avec des paramètres.
- Éviter la concaténation directe de données utilisateur dans les requêtes SQL.
- Limiter les messages d’erreur SQL affichés à l’utilisateur.
2. SQL Injection (Avancée)
Description : Injection SQL complexe exploitant des techniques comme les sous-requĂŞtes, UNION, time-based ou blind SQLi.
Contre-mesures :
- Toujours utiliser des ORM ou requêtes paramétrées.
- Désactiver l’affichage des erreurs SQL en production.
- Mettre en place une WAF pour bloquer les payloads connus.
3. XSS (Basic)
Description : Injection de code JavaScript dans une page non Ă©chappĂ©e (ex : ‹script› alert(1) ‹/script›).
Contre-mesures :
- Échapper les caractères spéciaux HTML (&, <, >, etc.).
- Utiliser des fonctions de templating sécurisées.
- Configurer Content Security Policy (CSP).
4. XSS (Avancée)
Description : XSS persistante ou DOM-based via des scripts injectés dans des champs stockés ou des URLs mal filtrées.
Contre-mesures :
- Éviter l’utilisation de innerHTML sans filtre.
- Encoder les entrées utilisateurs côté client et serveur.
- Utiliser CSP strictes et Subresource Integrity.
5. LFI (Local File Inclusion)
Description : Injection de chemins de fichiers via des variables GET, ex : ?file=../../../../etc/passwd
Contre-mesures :
- Ne jamais inclure des fichiers en fonction d’une entrée utilisateur directe.
- Utiliser une liste blanche de fichiers autorisés.
- Vérifier les chemins et extensions avec des expressions régulières.
6. Vol de cookies (modification locale)
Description : Un cookie modifiable (ex: isAdmin=true) permet un accès privilégié si le serveur ne vérifie pas.
Contre-mesures :
- Ne jamais stocker les rĂ´les en clair dans les cookies.
- Utiliser des sessions serveur ou des cookies signés.
- Vérifier les droits via une base de données côté serveur.
7. Accès aux fichiers .htpasswd
Description : Les fichiers sensibles (ex: .htpasswd) sont accessibles publiquement si mal protégés.
Contre-mesures :
- Configurer le serveur pour refuser l’accès aux fichiers .ht*.
- Utiliser un fichier .htaccess ou une config Nginx pour bloquer les fichiers cachés.
- Séparer fichiers sensibles hors du répertoire web accessible.
8. Bruteforce sur formulaire
Description : Un attaquant tente plusieurs identifiants/mots de passe jusqu’à trouver le bon.
Contre-mesures :
- Limiter les tentatives (captcha, délai entre essais).
- Utiliser une politique de verrouillage temporaire après X échecs.
- Surveiller les logs pour détecter les patterns anormaux.
9. File Upload
Description : Un utilisateur peut uploader des fichiers malveillants comme des scripts PHP, shell, etc.
Contre-mesures :
- Limiter les types de fichiers autorisés (whitelist).
- Renommer les fichiers uploadés.
- Stocker les fichiers hors du dossier public ou désactiver leur exécution.
10. Redirection non contrôlée
Description : Une redirection basée sur l’input utilisateur permet de rediriger vers des sites externes (phishing).
Contre-mesures :
- Ne jamais rediriger directement vers un paramètre GET non vérifié.
- Utiliser une liste blanche de destinations autorisées.
- Ajouter une Ă©tape de confirmation utilisateur.
11. Accès à /.hidden
Description : Un dossier caché ou fichier spécial est accessible car mal protégé.
Contre-mesures :
- Interdire l’accès aux répertoires ou fichiers cachés via la config du serveur.
- Utiliser un fichier index.html vide pour bloquer le listing.
- Vérifier que l’arborescence du projet ne laisse rien d’inutile exposé.
12. Formulaire de récupération de mot de passe
Description : Un formulaire de récupération envoie un message même si l’email n’existe pas — permet l’énumération des comptes.
Contre-mesures :
- Afficher un message générique (“si un compte existe, vous recevrez un mail…”).
- Logger en interne mais ne pas révéler le statut à l’utilisateur.
- Limiter les tentatives de récupération par IP ou session.
13. Spoofing via curl (Referer / User-Agent)
Description : Une ressource protégée est accessible si l’on forge des headers (Referer ou User-Agent) personnalisés.
Contre-mesures :
- Ne jamais se baser uniquement sur les headers pour vérifier l’authenticité.
- Utiliser une authentification robuste (tokens, sessions).
- Journaliser et analyser les headers suspects.
14. Bypass validation de formulaire (ex: input 1-10 → 12)
Description : Un champ de formulaire censé être limité est modifié dans la console pour contourner les restrictions client-side.
Contre-mesures :
- Toujours valider les entrées côté serveur.
- Ne jamais se fier uniquement Ă la validation JavaScript.
- Utiliser des contraintes strictes côté backend (type, intervalle, etc.).