WordPress.com ne chiffre pas le cookie contenant les identifiants
Sic.
Le 28 mai 2014 à 12h19
4 min
Internet
Internet
Le site Wordpress.com ne chiffre pas les contenus de certains cookies, dont celui qui contient les identifiants. Un problème de sécurité important et qui a permis à l’Electronic Frontier Foundation de montrer comment les informations pouvaient être récupérées et exploitées.
Pas de chiffrement pour un cookie pourtant crucial
Le site Wordpress.com, à ne pas confondre avec le système de gestion de contenu lui-même, contient actuellement une faille de sécurité assez importante. Lorsque l’on se connecte au service d’hébergement de blogs, un cookie contenant les identifiants est créé sur la machine. Le problème est que les informations qui y sont contenues ne sont pas chiffrées : les identifiants figurent en clair et sont donc lisibles par n’importe qui.
Yan Zhu, membre de l’Electronic Frontier Foundation, a réalisé des tests pour montrer la dangerosité de ce problème. Elle a simplement récupéré le cookie depuis son profil actif dans le navigateur, pour le copier vers un nouveau profil, donc sans aucun historique. Après la mise en place du fichier, elle s’est rendue sur Wordpress.com. Le site a directement accepté les identifiants présents dans le cookie sans poser de questions.
Le cookie en lui-même peut devenir facile à récupérer sur les réseaux Wi-Fi non protégés. Il n’est pas rare que des utilisateurs s’installent tranquillement sur une terrasse ou dans un lieu public et se mettent à écrire, notamment pour mettre à jour leur blog. Une personne malintentionnée pourrait alors surveiller les données qui transitent sur le réseau, et le cookie est d’autant plus simple à repérer qu’il contient la mention « wordpress_logged_in ».
Le compte peut être rendu totalement inaccessible
Il est aisé d’imaginer les conséquences d’une telle récupération, et Yan Zhu les présente d’ailleurs. D’une part, l’utilisation de ce cookie traverse toute étape d’authentification, même si le facteur double a été activé. D’autre part, une fois connecté au compte, le pirate peut modifier tous les contenus à sa guise. Enfin, il peut rendre le compte totalement inaccessible à son détenteur légitime en changeant l’adresse email de contact et en activant l’authentification à deux facteurs dans la foulée. Et la validité du cookie est par ailleurs un problème en elle-même puisqu’elle est de trois ans.
Andrew Nacin, développeur en chef du système de gestion Wordpress, a cependant tenu à apporter un certain nombre de précisions dans un communiqué envoyé à Ars Technica. Ainsi, il rappelle que le site Wordpress.com n’est pas tenu par Wordpress directement, mais par la société Automattic. La gestion en est donc indépendante et n’a pas de rapport direct avec le projet open source lui-même. Par ailleurs, il est certain que l’entreprise sera capable de gérer rapidement le problème car la solution à mettre en place semble simple.
De bonnes pratiques loin d'être toujours respectées
Il regrette cependant que l’annonce de l’EFF n’ait pas été faite plus en amont et directement aux personnes concernées avant de révéler publiquement le problème. Il ajoute également que le système Wordpress est déjà compatible avec les connexions SSL, du moins en bonne partie. Cependant, l’actuel travail sur la version majeure 4.0 sera l’occasion d’améliorer le support de SSL « out of the box », c’est-à-dire en l’activant d’office et pour tout le monde.
Le problème peut en outre être généralisé à l’ensemble des sites qui n’utilisent pas de connexion chiffrée pour des échanges importants de données personnelles. Mais dans une majorité de cas, Ars Technica note que les services d’hébergement Wordpress disposent d’un support complet du SSL avec des pages en HTTPS et de cookies chiffrés.
Dans un monde idéal, tous les utilisateurs devraient s’inquiéter de savoir si tout a été fait pour protéger ce genre d’opération. En attendant, il est important qu’un site aussi fréquenté que Wordpress.com applique autant de règles de bonne conduite que possible dans le domaine de la sécurité.
WordPress.com ne chiffre pas le cookie contenant les identifiants
-
Pas de chiffrement pour un cookie pourtant crucial
-
Le compte peut être rendu totalement inaccessible
-
De bonnes pratiques loin d'être toujours respectées
Commentaires (22)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 28/05/2014 à 12h35
" /> l’EFF !
Le 28/05/2014 à 12h57
Il n’y a que le chiffrement au niveau du transport (donc SSL) qui peut résoudre ce problème. Que le cookie lui-même soit chiffré ou non ne change rien… Le cookie d’auth de nextinpact est chiffré, mais rien ne m’empêche de le copier tel-quel sur n’importe quel autre browser pour récupérer ma session.
On peut résumer cette annonce à : “mon dieu, HTTP fait transiter les données en clair !”.
Le 28/05/2014 à 12h59
C’est quand même ouf de tomber sur des erreurs aussi débiles de nos jours… Si encore c’était un vieux site mort avec plus personne pour le mettre à jour, mais Wordpress.com quoi…
MrJul : oui je voulais faire la remarque. Mais il n’empêche que c’est la moindre des choses de ne pas faire circuler ce genre d’infos en clair.
Le 28/05/2014 à 13h04
Le 28/05/2014 à 13h04
MrJul : +1
C’est le cas partout, il suffit de copier un cookie sur un autre poste, et ça marche sur beaucoup de portail, tant qu’il n’y a pas d’association côté serveur de type “IP Cookie” qui permette une vérification, il n’est pas possible de passer à côté.
Le 28/05/2014 à 13h14
Le 28/05/2014 à 13h19
Le 28/05/2014 à 13h25
Le 28/05/2014 à 13h39
Le 28/05/2014 à 13h46
Ah juste comme ça si l’authentification est en http et pas en https cookie… ou pas cookie…
Le 28/05/2014 à 14h29
Je trouve que c’est enfoncer une porte ouverte.
Le problème est le même sur peut-être 95% des sites, NextINpact compris. A partir du moment où les données ne transitent pas en HTTPS, tous les cookies peuvent être potentiellement volés.
En PHP, le simple vol du PHPSESSID contenu dans le cookie est suffisant pour voler une session (et une protection IP ne suffit pas, il suffit que l’attaquant soit sur le même réseau privé que la victime pour avoir la même IP publique).
A ma connaissance, le seul moyen de limiter la casse, c’est de tout passer en HTTPS.
Le 28/05/2014 à 14h59
Je ne comprends pas l’intérêt d’appeler ça une faille. Le problème est plutôt qu’il ne faut pas se logger sur des sites non HTTPs critiques (pour soi) du moment qu’on est sur un réseau dont on est pas sûr de la sécurité. Wordpress se fait épingler parce que c’est un site servant de support à la publication de contenu monétisable.
C’est un problème présent sur tous les sites non HTTPS. Est-ce que tous les sites du monde auraient pour autant une raison valide et rentable d’être sécurisés à cette attaque ? Genre si je me fais piquer mon compte sur nextinpact.com est-ce que c’est grave ? Je vous laisse juger, moi ça m’empêchera pas de dormir…
Ca me rappelle cet article
Le 28/05/2014 à 15h08
Le 28/05/2014 à 15h39
Ainsi, il rappelle que le site Wordpress.com n’est pas tenu par Wordpress directement, mais par la société Automattic. La gestion en est donc indépendante et n’a pas de rapport direct avec le projet open source lui-même.
Ca c’est un peu foireux comme argument… J’ai un blog Wordpress auto-hébergé (et donc sans lien avec Wordpress.com), et j’ai quand même ce cookie.
Le 28/05/2014 à 15h40
Le 28/05/2014 à 15h43
Le 28/05/2014 à 16h32
Le 28/05/2014 à 17h05
Moi j’aime les cookies, surtout avec des grosses pépites de chocolats :)
Sinon ouais, à mon avis seule une protection via https peut protéger un cookie.
Le 28/05/2014 à 18h02
Le 28/05/2014 à 18h59
Bon, soyez gentils de ne pas chercher le mdp admin de mon blog sur Wordpress…
Sinon, je sens que je vais sans doute un de ces jours faire moi-même mon site, compte tenu du fait qu’avec un tiers dans le circuit, on ne contrôle rien, surtout les sécurités vitales…
Le 29/05/2014 à 12h37
Le 29/05/2014 à 17h52
Donc en fait le problème c’est que WordPress ne force pas le https pour les utilisateurs connecté. Oh wait… c’est pareil sur Next INpact !