Aller au contenu principal

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 :

  1. Installer Docker puis cloner le dépôt :
git clone https://github.com/digininja/DVWA.git
cd DVWA
  1. Lancer l’environnement :
docker-compose up -d
  1. Accéder à l’interface Web :
    http://localhost:8080

  2. Se connecter avec :

  • utilisateur : admin
  • mot de passe : password
  1. 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
  1. 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é
  1. 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


Quel type de faille permet d’exécuter du JavaScript dans le navigateur d’un utilisateur ?


Quel type de XSS est enregistré dans la base de données ?


Quelle injection permet de contourner une authentification ?


Quel type de faille repose sur le fait qu’un utilisateur est déjà connecté à un site ?


Quel outil est recommandé pour tester ces failles localement ?


Quel est le rôle d’un token CSRF ?


Quelle commande SQL est typique d’une injection ?


Quel en-tête HTTP peut être utilisé pour contrer une attaque CSRF ?


Quel outil permet de lancer DVWA rapidement ?


Quelle mesure de sécurité est efficace contre les failles XSS ?



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

astuce

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

É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

É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

É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

É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