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
ExpiresandCache-Controlpour 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