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