Connexion
Abonnez-vous

WordPress.com ne chiffre pas le cookie contenant les identifiants

Sic.

Wordpress.com ne chiffre pas le cookie contenant les identifiants

Le 28 mai 2014 à 12h19

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.

wordpress smith

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 ».

 

wordpress

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é.

Commentaires (22)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

<img data-src=" /> l’EFF !

votre avatar

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 !”.

votre avatar

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.

votre avatar







MrJul a écrit :



On peut résumer cette annonce à : “mon dieu, HTTP fait transiter les données en clair !”.







Non : mon dieu, WP ne renvoie pas vers SSL ses utilisateurs authentifiés.


votre avatar

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é.

votre avatar







MrJul a écrit :



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 !”.





-1



Le problème c’est que wordpress.com ne fait pas transiter les cookies d’authentification en https.

En plus une fois qu’il se soit déloggé de son compte le cookie était encore accepté comme vailde côté serveur <img data-src=" />



Wordpress.com a bien un cookie secure pour tout ce qui est accès à la partie admin du site (/wp-admin/), Ils auraient dû utiliser ce cookie pour tout ce qui est ajout de l’authentification double facteur & co.


votre avatar







Khalev a écrit :



Le problème c’est que wordpress.com ne fait pas transiter les cookies d’authentification en https.





Nous sommes donc bien d’accord sur le fait que le problème vient de la non utilisation de SSL/TLS et pas vraiment du cookie <img data-src=" />







Khalev a écrit :



En plus une fois qu’il se soit déloggé de son compte le cookie était encore accepté comme vailde côté serveur <img data-src=" />





Comme sur de très nombreux sites. Les cookies sont très rarement stockés côté serveur, juste validés.







Khalev a écrit :



Wordpress.com a bien un cookie secure pour tout ce qui est accès à la partie admin du site (/wp-admin/), Ils auraient dû utiliser ce cookie pour tout ce qui est ajout de l’authentification double facteur & co.





Là oui, s’ils ont déjà tout le mécanisme, ça craint un peu de ne pas l’avoir réutilisé.


votre avatar







MrJul a écrit :



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 !”.







Pareil, je dois avouer que j’ai du mal à voir la sécurité qu’apporte le chiffrement du cookie dans le cas de son vol. On évite peut-être que des infos comme le login apparaissent en clair, mais sorti de là…


votre avatar







MrJul a écrit :



..





J’ai tout de suite pensé à la même chose en lisant l’article…

Et effectivement la seule solution c’est d’agir sur le transport et pas sur le message.



A la limite une première sécurité serait d’invalider le cookie si l’ip de l’utilisateur à changé par rapport à sa dernière connexion et encore ça ne résout pas le problème d’un WIFI public.





votre avatar

Ah juste comme ça si l’authentification est en http et pas en https cookie… ou pas cookie…

votre avatar

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.

votre avatar

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


votre avatar







versgui a écrit :



(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).







Euh c’est peut être pas parfait mais c’est gravement limitant hein…



C’est comme pour le javascript a une certaine époque Dans 90% des cas on réutilise vite fait ce qui se fait mais on cherche pas à améliorer/sécuriser le bouzin


votre avatar



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.

votre avatar







damaki a écrit :



Je ne comprends pas l’intérêt d’appeler ça une faille.





Parce que le fait de pouvoir utiliser un cookie qui passe en clair qui ne s’invalide pas même après s’être déloggé pour changer un mot de passe et ajouter une seconde authentification c’est pas une faille?



La faille c’est pas seulement le fait que le cookie passe en clair, c’est aussi tout ce que tu peux faire avec un cookie qui apparemment ne disparaît de lui-même qu’après 3ans (!!!) ou après avoir changer le mot de passe.


votre avatar







tom103 a écrit :



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.





C’est surtout que lui ne peut pas intervenir là-dessus. Si un utilisateur de wordpress ne veut pas utiliser SSL il n’y peut rien à son niveau.

Par contre il promet d’améliorer la gestion du SSL et des cookies par WP ce qui n’est pas un mal. (Mais qui restera modifiable de toute façon par n’importe quel utilisateur)


votre avatar







caesar a écrit :



Euh c’est peut être pas parfait mais c’est gravement limitant hein…





Le cas le plus simple et commun de vol de cookie, c’est en sniffant ce qui passe sur un wifi public (Au MacDo…)



Dans ce cas qui est le plus commun, tu as en général la même IP que les autres (encore un cas où de l’IP V6 améliorerait les choses).


votre avatar

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.

votre avatar







MrJul a écrit :



Comme sur de très nombreux sites. Les cookies sont très rarement stockés côté serveur, juste validés.







En même temps le principe même d’un cookie c’est d’avoir une donnée servant de “clé” entre le client et le serveur. Un cookie est tout le temps stocké côté client. Le concept d’un cookie stocké sur le serveur n’a strictement aucun sens, cela impliquerait une communication avec seulement un seul acteur : le serveur avec lui même.


votre avatar

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…

votre avatar







Khalev a écrit :



La faille c’est pas seulement le fait que le cookie passe en clair, c’est aussi tout ce que tu peux faire avec un cookie qui apparemment ne disparaît de lui-même qu’après 3ans (!!!) ou après avoir changer le mot de passe.





Ok, là je suis d’accord. Le côté durée de vie des sessions et logoff, là c’est une faille


votre avatar

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 !

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 

Fermer