Exploitation de failles
Comprendre et tester les vulnérabilités Web courantes (XSS, SQLi, CSRF)
Notions théoriques
Les failles XSS, SQLi et CSRF sont parmi les plus fréquentes dans les applications Web.
Elles permettent à un attaquant d’interagir avec le site Web ou la base de données d’une manière non prévue par le développeur.
XSS (Cross-Site Scripting)
Une faille XSS permet à un attaquant d’injecter du code JavaScript malveillant dans une page Web. Ce code s’exécute dans le navigateur d’un utilisateur.
Il existe plusieurs types de XSS :
- XSS réfléchi : le script est injecté via une URL ou un formulaire, et s’exécute immédiatement.
- XSS stocké : le script est enregistré dans la base de données et s’exécute lorsqu’un autre utilisateur affiche la page.
- XSS DOM-based : la faille est dans le JavaScript côté client, qui traite mal les données d’entrée.
Conséquences :
- Vol de cookies/session
- Redirection vers un site malveillant
- Défiguration de page
- Envoi de requêtes à l’insu de l’utilisateur
SQLi (Injection SQL)
Une faille SQLi permet à un attaquant d’injecter des commandes SQL dans une requête prévue par le développeur. Cela arrive souvent lorsqu’un champ de formulaire est mal filtré.
Exemple :
SELECT * FROM users WHERE username = 'admin' AND password = '123';
Si l’utilisateur entre ' OR '1'='1
, la requête devient :
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';
Résultat : l’authentification est contournée.
Conséquences :
- Contournement d’authentification
- Lecture ou suppression de données
- Modification de la base de données
- Prise de contrôle du serveur si la base est mal sécurisée
CSRF (Cross-Site Request Forgery)
Le CSRF consiste à tromper un utilisateur connecté pour qu’il exécute une action à son insu sur un autre site (souvent en étant connecté).
Exemple : si un utilisateur est connecté à un site de banque, un site malveillant peut lui faire envoyer une requête à ce site (comme un virement), en utilisant son cookie de session.
Conditions :
- L’utilisateur est connecté
- Le site ne vérifie pas l’origine de la requête (pas de token CSRF)
Conséquences :
- Changement de mot de passe
- Virement bancaire
- Suppression de données
Défenses courantes
- Pour XSS : échapper les caractères spéciaux, utiliser des fonctions de filtrage côté serveur, activer le Content Security Policy (CSP)
- Pour SQLi : utiliser des requêtes préparées (requêtes paramétrées), ne jamais concaténer les entrées utilisateur
- Pour CSRF : utiliser des tokens CSRF, vérifier l’origine des requêtes (headers Referer/Origin)
Exemple pratique
Il est possible de tester ces failles sur un environnement de test local basé sur DVWA (Damn Vulnerable Web Application).
Télécharger et installer DVWA via Docker :
https://github.com/digininja/DVWA
Étapes :
- Installer Docker puis cloner le dépôt :
git clone https://github.com/digininja/DVWA.git
cd DVWA
- Lancer l’environnement :
docker-compose up -d
-
Accéder à l’interface Web :
http://localhost:8080 -
Se connecter avec :
- utilisateur :
admin
- mot de passe :
password
- Tester une faille XSS :
- Aller dans l’onglet "XSS (Reflected)"
- Entrer dans le champ :
<script>alert('XSS')</script>
- Valider et observer l’exécution du script
- Tester une faille SQLi :
- Aller dans "SQL Injection"
- Entrer un ID utilisateur classique :
1
- Puis tester avec :
1' OR '1'='1
- Observer le résultat retourné
- Tester une faille CSRF :
- Aller dans "CSRF"
- Modifier un mot de passe
- Observer le lien généré
- Copier ce lien dans une autre page HTML pour simuler une attaque
Test de mémorisation/compréhension
TP pour réfléchir et résoudre des problèmes
L’objectif de ce TP est de mettre en pratique les connaissances sur les failles XSS, SQLi et CSRF, sur une plateforme différente de DVWA : bWAPP (buggy Web application).
Cette application Web volontairement vulnérable permet de tester de nombreuses failles dans un environnement sécurisé.
Étape 1 — Installer l’environnement de test bWAPP avec Docker
Télécharger et exécuter bWAPP avec Docker.
URL du projet : https://github.com/raesene/bWAPP
Une solution
Vous devez être connecté pour voir le contenu.
Étape 2 — Réaliser une attaque XSS stockée
L’objectif est d’injecter un script JavaScript dans un champ de commentaire ou de message, qui sera affiché à d’autres utilisateurs.
Une solution
Vous devez être connecté pour voir le contenu.
Étape 3 — Réaliser une attaque SQLi simple
L’objectif est de contourner une authentification en injectant une commande SQL dans un champ de formulaire.
Une solution
Vous devez être connecté pour voir le contenu.
Étape 4 — Réaliser une attaque CSRF sur le changement de mot de passe
L’objectif est de créer une page HTML malveillante qui, lorsqu’elle est visitée par un utilisateur connecté, change son mot de passe sans son consentement.
Une solution
Vous devez être connecté pour voir le contenu.
Étape 5 — Proposer des protections pour chaque type d’attaque testée
Lister les protections efficaces contre les 3 types de failles testées (ce que bWAPP ne fait pas).
Une solution
Vous devez être connecté pour voir le contenu.