Honeypot pour les formulaires WordPress : comment ReportedIP Hive réduit le spam dans les commentaires à pratiquement zéro
Un champ « Honeypot » suffit à lui seul à bloquer les bots qui remplissent tous les champs de saisie ; il est toutefois inefficace face à un script conçu pour ignorer le seul champ qu’il devrait laisser vide. ReportedIP Hive 2.1.53 associe son « Comment Honeypot » existant à une protection contre l’exécution qui détecte également ce deuxième type de bot, et combine les résultats des deux pour que les soumissions automatisées n’atteignent pratiquement jamais la boîte de réception ou un fil de commentaires.
Comment fonctionne réellement un « Honeypot » WordPress ?
Un champ « Honeypot » est un champ de saisie supplémentaire ajouté à un formulaire, masqué aux visiteurs voyants grâce au CSS, masqué aux lecteurs d’écran à l’aide de la balise aria-hidden, et auquel aucun utilisateur non voyant ne peut accéder. Un script de soumission qui remplit tous les champs qu’il trouve remplit également celui-ci, et un Honeypot rempli constitue une preuve d’automatisation, sans aucune exception légitime. ReportedIP Hive en utilise un dans son formulaire de commentaires depuis la version 2.1.2 : un champ nommé reportedip_hive_hp, placé hors de l’écran, exclu de l’ordre de navigation au clavier et de la saisie automatique.
Pourquoi un « Honeypot » seul ne suffit plus
Un « Honeypot » ne détecte que les scripts qui remplissent les champs de manière aveugle. Un script conçu pour cibler un site spécifique, ou qui analyse le code d’un formulaire et ignore tout ce qui se trouve aria-hidden ou une classe hors écran, passe tout droit à côté. Les heuristiques de contenu ne peuvent pas non plus combler cette lacune, car la formulation évolue plus vite qu’un filtre ne peut l’apprendre. C’est pourquoi ReportedIP Hive 2.1.53 a ajouté une deuxième question indépendante : ce client a-t-il jamais chargé la page et exécuté son JavaScript ?
Cette question ne tient pas compte du contenu de la soumission. Un client qui publie directement à l’adresse wp-comments-post.php sans jamais avoir consulté la page de l’article ne peut pas avoir exécuté un script hébergé sur cette page, quel que soit le sujet évoqué dans le corps du commentaire.
Comment la preuve d’exécution aboutit à son verdict
Le serveur insère un champ d’ancrage caché dans le formulaire. Un petit script ajoute ensuite un deuxième champ à côté, dont le nom varie à chaque installation, de sorte qu’une Payload spécialement conçue ne puisse pas fonctionner sur deux sites différents. La lecture de ces deux champs lors de la soumission permet de classer chaque requête dans l’une des quatre catégories suivantes :
| Verdict | Contenu de la proposition | Ce que cela signifie |
|---|---|---|
tripped | Le champ « Honeypot », renseigné | Comportement typique d’un bot : remplir un champ qu’un humain ne voit jamais |
proved | Le « Honeypot » est vide, le champ de preuve est présent | Un navigateur a affiché le formulaire et a exécuté son script |
failed | Le « Honeypot » est vide, le champ de validation est manquant ; ce formulaire est connu pour l’afficher ainsi | On est arrivé sur une vraie page, le script ne s’est jamais exécuté, aucun indice permettant de conclure qu’un humain est à l’origine de tout ça |
absent | Aucun des deux champs n’est renseigné | Cette demande n’est jamais passée par notre formulaire |
La distinction entre failed et absent est importante pour un cas limite réel : un visiteur qui a désactivé JavaScript. Hive enregistre, au maximum une fois par jour, qu’un formulaire de commentaire a effectivement affiché l’ancre ; cet enregistrement permet de déterminer si l’absence d’un champ de preuve signifie « le script ne s’est jamais exécuté ici » ou « nous n’avons jamais intégré de champ dans ce formulaire ». Un thème comportant un balisage de commentaires écrit à la main, ou un site ayant désactivé cette couche, bénéficie d’une interprétation indulgente absent plutôt que d’être considéré comme suspect pour quelque chose qu’il n’a jamais eu.
Poids de chaque indicateur dans le score de spam
Les commentaires sont traités par un système de notation distinct, ReportedIP_Hive_Comment_Spam_Filterqui combine le verdict issu de l’analyse d’exécution avec des signaux liés aux liens et à l’identité. Un commentaire doit obtenir un score d’au moins 4 pour être classé comme spam :
| Signal | Score | Atteint-il à lui seul le seuil de 4 ? |
|---|---|---|
Champ « Honeypot » renseigné (tripped) | +6 | Oui, avec deux points d’avance |
La page a été affichée, mais le script ne s’est jamais exécuté (failed) | +4 | Oui, exactement sur la ligne |
| Le nom de l’auteur est en soi une URL | +4 | Oui |
| Un lien sans message dans un court commentaire | +4 | Oui |
| Le nombre de liens dépasse la limite maximale configurée | +3 | Non, il faut un deuxième signal |
La requête ne contient absolument aucun champ « Honeypot » (absent, pas d’historique de rendu) | +1 | Non, il faut un deuxième signal |
Un « Honeypot » rempli suffit à lui seul à franchir le seuil avec une marge confortable. Une preuve d’exécution manquante suffit à elle seule à le franchir exactement, ce qui est voulu : c’est le seul signal qu’un lecteur légitime ne disposant pas de JavaScript peut produire de lui-même ; le système se contente donc d’enregistrer le commentaire pour un examen manuel, plutôt que d’ajouter l’adresse à la liste des adresses IP bloquées.
La suite dépendra du formulaire
Les trois surfaces recouvertes par cette couche ne présentent pas le même risque ; elles n’entraînent donc pas les mêmes conséquences :
- Les commentaires dont le score dépasse le seuil sont classés comme spam ou rejetés d’emblée, selon la configuration choisie par le site dans « Pare-feu → Protection anti-spam ». Un visiteur dont le navigateur ne prend pas en charge JavaScript ne subit aucun inconvénient, si ce n’est un léger délai lié à la validation manuelle.
- Les formulaires d’inscription rejettent d’emblée toute soumission qui échoue et en expliquent la raison, car la création d’un nouveau compte représente un engagement plus important que la publication d’un commentaire.
- La réinitialisation du mot de passe est refusée si le « Honeypot » est rempli, mais jamais si seule la preuve fait défaut : un administrateur qui se retrouve bloqué hors de son propre site est pire que le spam que cette mesure permet d’empêcher ; ainsi, un navigateur sans JavaScript peut toujours récupérer un compte.
Chaque refus est traité en mode « ouvert ». Un quota de requêtes épuisé, un délai d’attente dépassé ou un réseau inaccessible sont interprétés comme une absence de décision plutôt que comme un blocage. L’activation du Report-Only Mode enregistre chaque verdict sans refuser la moindre soumission, ce qui s’avère utile pour consulter une semaine de journaux avant de décider des mesures à appliquer.
Depuis quand, et comment désactiver cette fonction ?
Le « Honeypot » des commentaires est opérationnel depuis la version 2.1.2 de Hive. La preuve d’exécution, le verdict à quatre voies et le système de notation mentionnés ci-dessus ont été intégrés à la version 2.1.53, parallèlement à l’extension du contrôle de réputation communautaire, qui ne s’appliquait auparavant qu’à la page de Login, aux commentaires, aux inscriptions et aux réinitialisations de mot de passe. Ces deux fonctionnalités sont disponibles gratuitement dans tous les forfaits.
L’ensemble de la couche de protection contre l’exécution se trouve sous « Pare-feu → Protection anti-spam », avec un commutateur valable pour l’ensemble du site et un autre dédié aux formulaires d’inscription et de réinitialisation de mot de passe. Un site dont le balisage des commentaires est suffisamment inhabituel pour déclencher de faux failed peut désactiver entièrement cette couche à l’aide de REPORTEDIP_HIVE_DISABLE_FORM_PROOF dans wp-config.php.
Foire aux questions
Un champ « Honeypot » peut-il bloquer un véritable visiteur ?
Pas en soi. Le champ « Honeypot » est invisible et inaccessible à toute personne utilisant une souris, un clavier ou un lecteur d’écran ; par conséquent, aucun utilisateur ne le remplit jamais. Le seul cas nécessitant une règle distincte concerne les visiteurs dont JavaScript est désactivé ; c’est pourquoi, en l’absence de preuve d’exécution, le système se contente d’enregistrer un commentaire pour examen plutôt que de bloquer l’adresse.
Le champ « Honeypot » a-t-il une incidence sur l’accessibilité ?
Ce domaine porte aria-hidden="true", un tabindex de -1 et autocomplete="off", de sorte que les technologies d’assistance et les gestionnaires de mots de passe l’ignorent, tout comme le ferait un utilisateur voyant utilisant une souris.
Un « Honeypot » sous forme de formulaire est-il conforme au RGPD ?
Le champ et le script de validation ne collectent aucune information sur le visiteur, si ce n’est la présence ou non de deux champs masqués au moment de l’envoi ; il n’y a ni empreinte numérique, ni requête vers un tiers. Consultez la documentation du plugin WordPress pour obtenir un résumé complet du traitement des données par ce plugin.
Lectures complémentaires
- Preuve de l’exécution du formulaire et nouveau guide de démarrage rapide, dans leur intégralité
- Un « Honeypot » d’un autre genre : bloquer les scanners dès leur première tentative d’accès au chemin d’accès d’un fichier appât
La documentation de référence du hook `comment_form` de WordPress indique où le champ « Honeypot » est affiché. Consultez la documentation du plugin WordPress pour obtenir la référence complète des paramètres. Découvrez ReportedIP Hive →