Cette attaque nécessite "juste" que quelqu'un puisse à un moment ou un autre intercepter vos communications. A l'heure du wifi, des LAN, etc, tout le monde est donc potentiellement vulnérable.

Imaginez que vous vous connectiez à votre compte de messagerie via un webmail. Vous êtes prudents et utilisez le protocole https. Vous vous connectez donc à https://www.monmail.net. Le site dépose sur votre disque un cookie qu'il utilisera lors de vos prochaines requêtes pour vérifier que vous êtes bien authentifié. La communication est chiffrée avec https, donc même si quelqu'un l'intercepte il y a peu de risque qu'il puisse en faire quelque chose.

Imaginons maintenant que Bill, un méchant, intercepte vos communications et soit capable d'y injecter du code. Un peu plus tard, vous surfez tranquillement sur un autre site, et Bill modifie la réponse du serveur pour y insérer une image hébergée sur le serveur où se trouve votre webmail:

<img src="http://www.monmail.net" style="display: none" />

Peu importe que l'image existe, il faut juste que son url soit en http. Votre navigateur reçoit la page, interprète le HTML, et envoie des requêtes pour charger toutes les images. Chaque fois qu'il envoie une requête vers un serveur, il ajoute dans l'entête l'ensemble des cookies définis pour ce domaine. Il va donc envoyer en clair au serveur monmail.net une requête contenant le cookie identifiant votre session. Peut importe la réponse du serveur, Bill ne cherche qu'à intercepter la requête de votre navigateur et son précieux cookie en clair. Il pourra ensuite utiliser le cookie pour se faire passer pour vous et accéder à votre compte. Et si, par commodité, le cookie a une durée de vie de quelques jours et que vous ne l'effacez pas vous-même (par exemple en vous déconnectant de votre compte), Bill n'a même pas à faire ça en direct, il pourra utiliser le cookie aussi longtemps qu'il sera valide.

En fait, ce n'est pas si simple, car le protocole HTTP permet d'éviter cette situation, en précisant que le cookie ne doit être transmis que si le canal est chiffré. Il faut pour cela ajouter l'attribut secure à l'entête définissant le cookie:

Set-Cookie: toto1=aaa; path=/
Set-Cookie: toto2=aaa; path=/; secure

Ici, le cookie toto2 ne sera transmis qu'à travers des connexions sécurisées. (cf la RFC 2965).

En PHP, pour positionner cet attribut, il faut utiliser le paramètre secure de la fonction setcookie. Attention, par défaut les cookies utilisés pour les sessions ne sont pas sécurisés, vous devez utiliser le paramètre session.cookie_secure du fichier php.ini.

Malheureusement, d'après Mike Perry, de très nombreux sites web, dont gmail, n'utilisent pas de cookies sécurisés, et sont donc vulnérables à ce genre d'attaques ! Il affirme les avoir prévenus du danger il y a plus d'un an. Malheureusement, bon nombre de sites n'ont pas encore pris les mesures pour corriger ce problème. Pour les inciter à s'activer, Mike a donc développé CookieMonster, un programme permettant d'automatiser ce vol de cookies.

Et vous, est-ce que les sites que vous développez sont vulnérables ?

Pour aller plus loin: