Imaginez la situation suivante : vous vous connectez à votre compte bancaire avec votre identifiant, votre mot de passe, et un code de sécurité envoyé sur votre téléphone. Vous pensez être parfaitement protégé, n'est-ce pas ?
Et pourtant, il existe une technique qui permet à un attaquant de contourner complètement l'authentification à 2 facteurs et d'accéder à votre compte sans connaître ni votre mot de passe, ni votre code de sécurité. Cette technique s'appelle le vol de cookies de session.

Dans cet article, nous allons comprendre comment fonctionne cette attaque, comment vous pouvez la tester sur vos propres comptes pour comprendre le risque, et surtout, comment vous en protéger.
|
AVERTISSEMENT IMPORTANT : Cet article et la vidéo associée décrivent des techniques de sécurité à des fins éducatives uniquement. L'utilisation de ces techniques pour accéder sans autorisation aux comptes d'autrui est ILLÉGALE et punissable par la loi (Article 323-1 du Code Pénal : 2 ans d'emprisonnement et 60 000€ d'amende). Les exemples présentés doivent être testés UNIQUEMENT sur vos propres comptes et machines. |
Vidéo associée
1. Qu'est-ce qu'un Cookie de Session ?
Le Cookie : votre badge d'identité en ligne
Lorsque vous vous connectez à un site web (Gmail, Facebook, votre banque, …), le serveur du site crée ce qu'on appelle un cookie de session. C'est un petit fichier texte stocké dans votre navigateur qui contient un identifiant unique.
Historiquement, un cookie est un petit fichier texte stocké par votre navigateur web. Il contient un identifiant unique et des informations sous forme de paires clé-valeur (ex : session=abc123, user=alice).
Dans la plupart des navigateurs modernes les cookies ne sont pas des fichiers texte indépendants. Ils sont stockés dans une base de données SQLite. Même en SQLite, les valeurs sont du texte non chiffré
Pensez au cookie comme à un badge d'accès dans une entreprise :
- Vous montrez votre carte d'identité à la réception (= login + mot de passe + 2FA)
- On vous donne un badge d'accès temporaire (= cookie de session)
- Avec ce badge, vous pouvez circuler librement sans remontrer votre carte d'identité (= navigation sur le site)
- Le badge expire à la fin de la journée (= déconnexion ou expiration du cookie)
Le problème c’est quand quelqu'un vole votre badge...
Le cookie de session est tout ce dont le site a besoin pour vous identifier. Si un attaquant réussit à voler votre cookie (votre badge), il peut :
- Se faire passer pour vous auprès du site web
- Accéder à votre compte SANS connaître votre mot de passe
- Contourner complètement l'authentification à 2 facteurs
C'est exactement comme si quelqu'un volait votre badge d'entreprise : il peut entrer dans le bâtiment sans avoir besoin d’une carte d'identité.
2. Comment Fonctionne le Vol de Cookies ?
Les Méthodes d'Attaque
Il existe plusieurs façons pour un attaquant de voler vos cookies :
- Malware sur votre ordinateur : Un logiciel malveillant peut lire directement les fichiers de cookies stockés par votre navigateur.
- Attaque Man-in-the-Middle (MitM) : Sur un réseau Wi-Fi public non sécurisé, un attaquant peut intercepter vos communications.
- Script XSS (Cross-Site Scripting) : Injection de code JavaScript malveillant dans un site web vulnérable.
- Accès physique à votre machine : Quelqu'un qui a accès à votre ordinateur déverrouillé.
- Extension de navigateur malveillante : Une extension qui prétend offrir une fonctionnalité utile mais vole vos cookies en arrière-plan.
Pourquoi la 2FA Ne Suffit Pas ? : C'est ici que la faille devient critique. L'authentification à 2 facteurs (2FA) est excellente pour protéger votre première connexion. Mais une fois connecté, le site vous fait confiance grâce à votre cookie de session.
Résultat : Un attaquant qui vole votre cookie n'a jamais besoin de votre mot de passe ou de votre code 2FA. Il utilise directement votre session déjà authentifiée.
3. Test Pratique : comprendre le risque par soi-même
|
CADRE ÉTHIQUE ET LÉGAL : Le test suivant doit être effectué UNIQUEMENT :
Tester cette technique sur le compte de quelqu'un d'autre sans autorisation constitue un délit pénal. Ne le faites jamais, même "pour plaisanter" ou "pour tester". |
Nous allons voir 3 méthodes exposées ci-après.
3.1. Test avec les outils de développement
Tous les navigateurs modernes incluent des outils de développement qui permettent de voir et manipuler les cookies. Voici comment tester le vol de cookies sur votre propre compte :
Étape 1 : Connexion Initiale
- Ouvrez votre navigateur (Chrome, Firefox, Edge, etc.)
- Connectez-vous à un site de test (par exemple : Gmail, Facebook, ou tout autre compte que vous possédez)
- Une fois connecté, appuyez sur F12 pour ouvrir les Outils de Développement du navigateur (ou faire un clic droit et choisir « Inspecter » sur Firefox)
Étape 2 : Extraction des Cookies
- Allez dans l'onglet "Application" (Chrome) ou "Stockage" (Firefox)
- Dans le menu de gauche, cliquez sur "Cookies" puis sur le nom du site
- Vous verrez une liste de tous les cookies stockés. Cherchez le cookie de session (souvent nommé : "session_id", "auth_token", "PHPSESSID", etc.)
- Copiez la valeur de ce cookie (clic droit → Copier, ou sélectionner et Ctrl+C). Vous pouvez aussi identifier les cookies de session en cherchant des cookies nommés : `session`, `sessionid`, `PHPSESSID`, `auth_token`, `access_token`. Notez le nom et la valeur de chaque cookie pertinent
Exportez les informations :
- Clic droit sur chaque cookie → "Copier"
- Créez un fichier texte sur votre clé USB : cookies_session.txt
Collez les informations dans ce format
- Nom du cookie : [nom]
- Valeur : [valeur]
- Domaine : [domaine]
- Chemin : [chemin]
- Expire : [date]
- HttpOnly : [oui/non]
- Secure : [oui/non]
Étape 3 : Simulation du Vol (sur un autre ordinateur)
- Ouvrez une fenêtre de navigation privée / incognito (Ctrl+Shift+N sur Chrome)
- Allez sur le même site (mais NE vous connectez PAS)
- Ouvrez à nouveau les Outils de Développement (F12)
- Allez dans Console** et exécutez (code javascript) :
- document.cookie = "nom_du_cookie=valeur_du_cookie; domain=.domaine.com; path=/; SameSite=None; Secure";
- Rafraîchissez la page (F5)
Résultat : Vous êtes maintenant connecté au compte sans avoir entré de mot de passe ni de code 2FA ! Le navigateur en mode incognito utilise le cookie volé pour vous identifier.
3.2. Accès Direct au Fichier de Cookies
1. Localisez le profil Firefox :
- Dans Firefox, tapez `about:support` dans la barre d'adresse
- Cliquez sur "Ouvrir le dossier" à côté de "Dossier de profil"
2. Copiez le fichier cookies :
- Trouvez le fichier `cookies.sqlite`
- Copiez-le sur votre clé USB
Note : Firefox doit être fermé pour copier ce fichier car pendant son ouverture Firefox crée des fichiers temporaires de transaction avec le serveur et la base SQLite se met à jour à la fermeture de Firefox. De plus pour que cette méthode fonctionne il faut que le navigateur soit paramétré pour garder les cookies.
Restauration des Cookies (Ordinateur 2)
- Fermez Firefox complètement sur l'ordinateur 2
- Localisez le profil Firefox (comme à l'étape précédente)
- Remplacez le fichier `cookies.sqlite` par celui copié sur l’ordinateur 1
- Redémarrez Firefox
Accédez au site : vous serez connecté automatiquement
3.3. Test avec une extension de gestion de cookies
Pour une approche encore plus simple (et visuelle), vous pouvez utiliser une extension de navigateur (voir la vidéo associée):
1. Installez l'extension "Cookie-Editor" :
- Allez sur Firefox Add-ons
- Recherchez "Cookie-Editor" par cgagnier
- Installez l'extension
2.Exportez les cookies :
- Cliquez sur l'icône de l'extension
- Cliquez sur "Export" → "Export as JSON"
- Sauvegardez le fichier sur une clé USB par exemple
Récupérer les cookies sur le second ordinateur
- Installez Cookie-Editor sur le second ordinateur
- Accédez au site (sans vous connecter)
- Ouvrez l'extension
- Cliquez sur "Import"
- Collez le JSON copié depuis la clé USB
- Rechargez la page
Vous êtes connecté sans authentification !
3.4. Nettoyage post-démonstration
Après vos tests, il est conseillé de nettoyer les ordinateurs concernés. Checklist de Nettoyage
- [ ] Déconnexion du compte de test sur les deux ordinateurs
- [ ] Suppression des cookies exportés de la clé USB
- [ ] Effacement de l'historique et cookies des navigateurs
- [ ] Suppression du compte de test si nécessaire
- [ ] Vérification qu'aucune session n'est restée active
Commandes de Nettoyage
Sur Firefox :
- `Ctrl + Shift + Suppr`
- Sélectionner "Tout"
- Cocher : Historique, Cookies, Cache
- Cliquer "Effacer maintenant"
Effacer la clé USB de manière sécurisée : Commande batch : cipher /w:E:\
4. La démonstration de la vidéo
La vidéo jointe au début de cet article montre un vol de cookies que vous pouvez réaliser facilement.
Le Scénario
- Machine Victime : Un ordinateur Windows avec Firefox, connecté à un compte de test protégé par authentification à 2 facteurs
- Machine Attaquant : Un ordinateur sur le même réseau local (mais ce n’est pas obligatoire) utilisant un autre navigateur.
- Outil utilisé : Le plug-in cookies Editor pour extraire et transférer les cookies, un script bat qui transmet les cookies sur un site. On pourrait bien sûr imaginer un programme qui pourrait faire cela automatiquement, mais la démonstration manuelle est impressionnante et a l’avantage de montrer clairement le mécanisme.
Les faits marquants de ce test :
- La rapidité : En quelques secondes, nous avons accès au compte
- Le bypass Total de la 2FA : Aucun code de sécurité n'a été demandé à l'attaquant
- L'invisibilité : La victime reste connectée et ne se doute de rien
- La simplicité : Pas besoin d'être un expert en hacking
5. Comment se Protéger du Vol de Cookies ?
Voici quelques scénarios d'attaques réelles
1. Café/bibliothèque :
- L’utilisateur laisse son ordinateur 2 minutes
- L’attaquant copie les cookies en 30 secondes
- L’attaquant a accès au compte depuis n'importe où
2. Malware :
- Logiciel malveillant vole les cookies
- Envoi à l'attaquant
- Accès distant aux comptes
3. Réseau WiFi compromis :
- Sans HTTPS, cookies interceptés
- Attaque "Man-in-the-Middle"
- Vol de session en temps réel
Le risque étant compris, voici les mesures concrètes à mettre en place :
Protection Niveau Utilisateur (Ce que vous pouvez faire)
1. Déconnexion systématique
- Déconnectez-vous TOUJOURS de vos comptes sensibles (banque, courriel, etc.) quand vous avez fini
- Ne cochez jamais "Rester connecté" sur des ordinateurs publics ou partagés
- Sur votre propre ordinateur, déconnectez-vous au moins une fois par semaine
2. Sécurité du réseau
- Évitez les Wi-Fi publics pour accéder à vos comptes sensibles
- Si vous DEVEZ utiliser un Wi-Fi public, utilisez un VPN de confiance
- Vérifiez que le site utilise HTTPS (cadenas dans la barre d'adresse)
3. Hygiène de sécurité
- N'installez que des extensions de navigateur de sources fiables
- Maintenez votre système et votre antivirus à jour
- Ne laissez jamais votre ordinateur déverrouillé sans surveillance
- Videz régulièrement les cookies de votre navigateur (au moins une fois par mois)
4. Surveillance des sessions actives
De nombreux services permettent de voir les sessions actives sur votre compte :
- Gmail : Paramètres → Comptes → Activité du compte → Gérer les appareils
- Facebook : Paramètres → Sécurité → Où vous êtes connecté
- Amazon : Compte → Connexion et sécurité → Appareils
Vérifiez régulièrement et déconnectez toute session suspecte ou non reconnue.
Protection niveau développeur (pour les sites Web)
Si vous êtes développeur web, voici les mesures techniques à implémenter :
- Attribut HttpOnly : Empêche JavaScript d'accéder aux cookies (protection contre XSS)
- Attribut Secure : Force l'envoi du cookie uniquement sur HTTPS
- Attribut SameSite : Limite l'envoi de cookies aux requêtes provenant du même site
- Rotation des Tokens : Régénérer le cookie de session régulièrement
- Vérification de l'IP / User-Agent : Détecter les changements suspects de contexte
- Timeout de Session : Déconnexion automatique après inactivité
6. Les protections bancaires contre le vol de cookies
Les banques utilisent des techniques de sécurité bien plus avancées que les sites web classiques. Voyons comment elles se protègent.
6.1. Techniques de Protection des Banques
1. Device Fingerprinting (Empreinte d'appareil)
Les banques ne se contentent pas uniquement du cookie, elles créent une "empreinte numérique" de votre appareil :
Informations collectées :
- Modèle exact du smartphone/ordinateur
- Système d'exploitation et version
- Résolution d'écran
- Liste des capteurs (gyroscope, accéléromètre)
- Fuseau horaire
- Langue du système
- Adresse IP
- Localisation GPS (avec autorisation)
- Empreinte unique de l'appareil (IMEI, Android ID, UUID iOS)
Résultat : Même si quelqu'un vole votre cookie, le serveur bancaire détecte que la requête provient d'un appareil différent et la connexion est refusée.
6.2. L’exemple du Certicode de la Banque Postale
Le système Certicode combine plusieurs couches :
A. Enregistrement initial du smartphone
- Installation de l'application La Banque Postale
- Processus d'enrôlement (identifiant + mot de passe + code reçu par SMS)
- Génération d'un certificat cryptographique unique stocké dans l'appareil
- Association de ce certificat à votre compte côté serveur
B. À chaque connexion
- Vous entrez votre code Certicode (4 ou 6 chiffres)
- L'application génère un "jeton" cryptographique signé avec le certificat
- Ce jeton est envoyé au serveur avec votre requête
- Le serveur vérifie que :
- Le certificat correspond à celui enregistré
- L'appareil est bien celui déclaré
- Le code Certicode est correct
- La signature cryptographique est valide
Peut-on voler le cookie d’une connexion bancaire ?
Techniquement le cookie peut être volé, mais le cookie seul est inutile car :
1. Vérification multi-facteurs :
- Cookie volé → mais insuffisant
- Certificat de l'appareil → manquant
- Device fingerprint → appareil différent
- Signature cryptographique → impossible à reproduire
2. Liaison appareil-session :
- La session est liée à l'empreinte exacte du smartphone
- Même avec le cookie, depuis un autre appareil → échec
- Le serveur détecte l'incohérence immédiatement
3. Challenge-Response :
- Pour certaines opérations sensibles (virement, etc.)
- Le serveur envoie un "défi" (nombre aléatoire)
- Seul le certificat stocké dans votre smartphone peut répondre correctement
- Impossible à répliquer sans l'appareil physique
Scénario d'attaque et pourquoi ça échoue
L’attaquant vole votre cookie de session bancaire :
1. Tente de se connecter avec le cookie volé
- Serveur détecte : Appareil inconnu, IP différente
- Demande de réauthentification
2. L’attaquant entre identifiant + mot de passe (s'il les a)
- Serveur demande : Code Certicode
- Attaquant ne peut pas le générer (pas l'appli sur le bon smartphone)
3. Même si l’attaquant a le code Certicode (observation)
- Serveur vérifie la signature cryptographique
- Signature invalide (pas le bon certificat)
- BLOCAGE + Alerte de sécurité envoyée à l'utilisateur
6.3. Autres Mécanismes de Protection Bancaires
1. Tokens à Durée de Vie Très Courte
- Session bancaire typique le token expire au bout de 5 minutes seulement.
- Toutes les 5 minutes il y a une demande de nouveau token.
- Si la session est expirée ou qu’il n’y a pas eu d’action il faut se reconnecter. Un cookie volé devient donc inutile et inopérant après 5 minutes.
2. Détection d'Anomalies en Temps Réel
Les banques utilisent de l'IA pour détecter des comportements suspects :
- Connexion depuis un nouveau pays
- Navigation inhabituelle (pages visitées différentes)
- Vitesse de frappe au clavier différente
- Mouvements de souris inhabituels
- Horaires de connexion atypiques
- Montants de virements anormaux
Réaction : Blocage temporaire + demande de validation supplémentaire (SMS, appel téléphonique).
3. Validation Géographique
Dernière connexion : Paris (France)
Nouvelle connexion : 5 minutes plus tard → Pékin (Chine)
- IMPOSSIBLE physiquement
- BLOCAGE automatique
- Alerte immédiate par SMS/email
4. Cloisonnement des Opérations
Même connecté, certaines opérations nécessitent une revalidation :
- Consultation du solde : OK avec session simple
- Virement < 500€ : Code Certicode requis
- Virement > 500€ : Code Certicode + confirmation SMS
- Ajout de bénéficiaire : Code Certicode + délai de 24-48h
- Changement de coordonnées : Appel téléphonique de vérification
Résultat : Même avec accès à la session, l'attaquant ne peut rien faire de critique.
6.4. Technologies Utilisées par les Banques
A. Certificats Client (TLS Mutual Authentication)
Connexion classique (HTTPS) :
- Client → Vérifie le certificat du serveur → ok
- Connexion bancaire renforcée :
- Client → Vérifie le certificat du serveur → ok
- Serveur → Vérifie le certificat du client → ok
Le certificat client est stocké de manière sécurisée dans votre smartphone.
B. Sur iOS et Android modernes :
Zone sécurisée du processeur où sont stockés :
- Certificat cryptographique
- Clés privées
- Données biométriques (empreinte digitale, Face ID)
- Inaccessible même avec accès root/jailbreak
- Chiffrement matériel
- Impossible à extraire
C. Tokenisation
Au lieu de stocker votre vrai numéro de compte :
- Numéro de compte réel : 12345678901234
- Token utilisé dans l'appli : 98f7d6e5c4b3a2
- Mapping serveur : Token → Compte réel
Même si l'appli est compromise, le vrai numéro n'est jamais exposé.
6.5. Comparaison : site web classique vs banque
Avec le système Certicode de La Banque Postale pris en exemple, même si quelqu'un vole votre cookie de session, il ne pourra pas accéder à votre compte car :
Il n'a pas le certificat cryptographique (stocké dans votre smartphone)
- Il n'a pas l'empreinte exacte de votre appareil
- Il ne peut pas générer la signature cryptographique
Le serveur détectera immédiatement l'anomalie. Les banques ont 10-15 ans d'avance en sécurité par rapport aux sites web classiques, car :
- Il existe une obligation réglementaire (DSP2 en Europe)
- Les enjeux financiers sont énormes
- La banque peut être responsable en cas de fraude
- Les budgets sécurité sont importants
Le vol de cookie est une menace réelle pour les sites classiques, mais quasi-inefficace contre les applications bancaires modernes grâce à ces multiples couches de protection. C'est pour cela que les banques insistent tant pour que vous utilisiez uniquement l'application officielle et jamais le navigateur web mobile pour vos opérations sensibles !
7. La sécurité est une responsabilité Partagée
Le vol de cookies de session révèle une vérité inconfortable : même les meilleures protections (mots de passe forts, 2FA) peuvent être contournées si nous ne comprenons pas comment fonctionnent nos outils numériques.
Les Points Clés à Retenir
- La 2FA n'est pas infaillible : Elle protège la connexion initiale, mais pas la session active
- Les cookies sont précieux : Traitez-les comme des clés de votre maison
- La déconnexion est essentielle : C'est le moyen le plus simple et efficace de se protéger
- Soyez vigilants : Wi-Fi publics, extensions suspectes, ordinateurs non sécurisés sont autant de risques
Vous êtes maintenant informés. Vous comprenez le risque et savez comment vous protéger. La sécurité informatique n'est pas une question de perfection, mais de réduction des risques. Chaque mesure que vous mettez en place rend votre vie numérique plus sûre.
|
À RETENIR 1 - Déconnectez-vous de vos comptes sensibles 2 - Évitez les Wi-Fi publics pour les opérations sensibles 3 - Surveillez les sessions actives sur vos comptes 4 - Videz vos cookies régulièrement |
Ressources Complémentaires
Pour aller plus loin :
- OWASP Session Management : https://owasp.org/www-community/Session_Management_Cheat_Sheet
- Mozilla Developer Network (Cookies): https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
- ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) : https://www.ssi.gouv.fr/
Article rédigé par le Club Informatique à partir des notes de la réunion du 13/02/2026.