Catégories
Releases WordPress

🐛 WordPress 5.4.2 : un correctif pour contrer le rĂ©fĂ©rencement des commentaires spams en attente de modĂ©ration

PrĂ©vue pour mercredi 10 juin et dirigĂ©e par Jake Spurlock avec l’aide de Sergey Biryukov, Jonathan Desrosiers et votre serviteur, la version mineure 5.4.2 de WordPress corrige une vingtaine de bugs.

L’un d’entre eux est un bug important qui affecte toutes les versions de WordPress depuis la version 5.1. Comme indiquĂ© dans cette devnote (en anglais), il permet, via un dĂ©tournement assez vicieux, Ă  des personnes mal intentionnĂ©es de faire rĂ©fĂ©rencer dans les moteurs de recherche des commentaires pourtant en attente de modĂ©ration sur un site.

Le correctif associé sera déployé sur les branches 5.1, 5.2, 5.3 et 5.4 de WordPress.

La mise à jour WP 5.4.2 est prévue pour le mercredi 10 juin 2020 entre 18 et 21 heures.

Pour rĂ©sumer, mettez Ă  jour vers WordPress 5.4.2 dĂšs que vous en aurez l’occasion, et d’ici lĂ , validez ou supprimez tous vos commentaires en attente de modĂ©ration !

Si vous tenez Ă  en savoir plus sur ce bug, son origine et ses consĂ©quences, lisez ce qui suit đŸ‘‡ đŸ€“

⚙L’origine du bug : WordPress 5.1 et la gestion de la prĂ©visualisation des commentaires en attente de modĂ©ration

Si le bug a Ă©tĂ© introduit dans WordPress 5.1, ses origines datent en rĂ©alitĂ© d’il y a un peu plus longtemps.

⏱Petit retour en arriĂšre : 2018 et le RGPD

Depuis bien longtemps, WordPress permet Ă  un visiteur dont le commentaire est en attente de modĂ©ration de le prĂ©visualiser, en le reconnaissant Ă  l’aide d’un cookie dĂ©posĂ© sur son navigateur. Depuis WordPress 4.9.8, qui contenait tout un tas de correctifs liĂ©s Ă  la confidentialitĂ© des donnĂ©es et au RGPD, il faut que l’utilisateur ait donnĂ© son consentement pour que ce cookie soit dĂ©posĂ© sur son navigateur.

DĂšs lors, la prĂ©visualisation des commentaires n’Ă©tait plus disponible pour les visiteurs n’ayant pas consenti au dĂ©pĂŽt de ce cookie. Une parade a Ă©tĂ© trouvĂ©e et mise en place sur WP 5.1 : utiliser une variable dans l’URL pour stocker un hash gĂ©nĂ©rĂ© pour le commentaire, et afficher le commentaire en attente de modĂ©ration uniquement si l’URL contient ce hash pour la variable associĂ©e. Pour ceux que ça intĂ©resse, voici le ticket contenant le patch introduisant ce bug.

đŸŽâ€â˜ ïžUn procĂ©dĂ© dĂ©tournĂ© par les spammeurs

Quand il s’agit de rĂ©fĂ©rencement, les gens sont capables de faire montre d’une certaine ingĂ©niositĂ© ! En dĂ©tournant ce process, il est possible d’utiliser un site pour y afficher des liens de spam et le faire savoir Ă  Google, sans que ces liens soient physiquement affichĂ©s pour les visiteurs normaux du site.

Voici le procĂ©dĂ© complet :

Mettons que je veuille faire croire Ă  Google qu’un site bĂ©nĂ©ficiant d’une bonne rĂ©putation a publiĂ© des liens vers mon site en les autorisant dans mes commentaires.

Il me suffit de publier un commentaire contenant mes liens à référencer et de ne pas accepter le dépÎt de cookies par le site sur mon navigateur (case à cocher disponible lors de la soumission du commentaire).

Comme mon commentaire plein de liens est un peu suspect, le site va alors passer mon commentaire en attente de modĂ©ration. De mon cĂŽtĂ©, en front, aprĂšs soumission du formulaire de commentaire, la page se recharge, et affiche mon commentaire en prĂ©visualisation, prĂ©cĂ©dĂ© de la mention « Votre commentaire est en attente de modĂ©ration Â».

Si je suis attentif, je peux constater que l’URL de cette page (la page oĂč mon commentaire est en attente de prĂ©visualisation) contient bien un hash, permettant de savoir que je suis bien l’auteur du commentaire, et donc de le fournir en prĂ©visualisation.

L’ensemble du process est automatisable par les spammeurs, afin de gĂ©nĂ©rer les commentaires ainsi que les pages de spam sur le site sur lequel Google passera de façon automatisĂ©e.

Il me suffit alors de copier cette URL, puis de la coller sur un site tiers un minimum connu de Google. Le script d’indexation de Google suivra alors ce lien et tombera sur la page de ce site « bidule Â» qu’il connait dĂ©jĂ  favorablement. Comme le lien suivi par Google dispose du hash, il verra mon commentaire pourtant toujours en attente de modĂ©ration et pourra donc considĂ©rer que ce site fait volontairement un lien vers mon site « machin Â».

Cette « astuce Â» part du principe que les commentaires en attentes de modĂ©ration (surtout s’ils sont rangĂ©s dans les spams) ne sont pas frĂ©quemment triĂ©s par les administrateur·ice·s de sites web. Ce qui est sans doute le cas : on ne passe pas notre temps Ă  inspecter le tableau de bord de son site pour filtrer les commentaires en attente.

Il m’a suffit d’une trentaine de minutes pour faire un proof-of-concept en envoyant des requĂȘtes cURL vers l’API disponible sur wp-comments-post.php. Le feedback cURL retournant l’URL contenant le hash de prĂ©visualisation, il est assez simple de scripter la gĂ©nĂ©ration de liens.

D’ailleurs, une recherche rapide montre que plus de 700 000 URL contenant le hash de modĂ©ration existent dans les rĂ©sultats de recherche sur Google.

🧯Correction du bug dans WordPress 5.4.2

WordPress 5.4.2 corrige ce bug en ne permettant pas de prĂ©visualiser un commentaire en attente de modĂ©ration plus de 60 secondes aprĂšs sa soumission. Cette durĂ©e permet au visiteur de recevoir un feedback et savoir que son commentaire est en attente de validation, mais ne permet pas d’exploiter cette prĂ©visualisation auprĂšs des moteurs de recherche.

Voici la liste prĂ©cise des diffĂ©rents correctifs ayant permis d’aboutir Ă  un patch complet du bug :

  • Suppression de la prĂ©visualisation des commentaire non validĂ©s aprĂšs 1 minute, pour Ă©viter tout accĂšs public Ă  partir du hash de modĂ©ration
  • Passage des paramĂštres d’URL uniquement si le visiteur n’a pas consenti au dĂ©pĂŽt de cookies
  • Ajout des en-tĂȘtes HTTP Expires and Cache-Control pour les CDN et autres services de cache
  • Affichage du commentaire uniquement lorsque les paramĂštres d’URL sont prĂ©sents dans la requĂȘte
  • Masquage du bouton de rĂ©ponse Ă  un commentaire en attente de modĂ©ration s’il est affichĂ© du fait de la prĂ©sence d’un hash dans l’URL

🚀Un correctif exceptionnellement dĂ©ployĂ© sur quatre branches de WordPress: 5.1, 5.2, 5.3 et 5.4

En temps normal, seuls les correctifs de sĂ©curitĂ© sont dĂ©ployĂ©s sur d’anciennes versions de WordPress, mais vu l’importance du problĂšme, ce correctif sera exceptionnellement dĂ©ployĂ© sur les 4 branches de WordPress concernĂ©es : 5.1, 5.2, 5.3 et 5.4 qui auront donc chacune une nouvelle version mineure Ă  disposition.

Ainsi si votre site tourne encore sur WordPress 5.3 (pour rappel : il n’est pas du tout recommandĂ© de ne pas ĂȘtre Ă  jour 😉), vous pourrez mettre Ă  jour vers WP 5.3.4. Si vous utilisez WP 5.2, alors 5.2.7 sera disponible. Et si vous ĂȘtes sur WP 5.1 (ça commence Ă  dater, faites attention !), alors la version 5.1.6 vous permettra de corriger ce bug.

N’oubliez pas, la seule version de WordPress activement maintenue, c’est la branche courante ! Les autres ne font que recevoir des correctifs de sĂ©curitĂ©.

📚Sources consultables publiquement

Tout d’abord un grand merci Ă  Jon Kolbert, membre du staff de Wikimedia d’avoir initialement remontĂ© ce bug 👍

Voici le commit contenant les changements de code effectués sur WP 5.4.2 concernant ce bug, ainsi que le ticket Trac pour consulter les échanges qui y ont eu lieu.

Voici enfin la note Ă  destination des dĂ©veloppeuses et des dĂ©veloppeurs (devnote) concernant cette correction :


Photo de banniĂšre par Thomas Fields

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Mentions légales