[Retour] Contrer des robots stupides sans captcha
C'est un post rapide qui va permettre de faire un retour sur la solution pour contrer les robots sans utiliser de captcha.
Pour rappel, le concept est simple : on place dans l'action du formulaire un mot clé qui invalide sa soumission. Ce mot clé est supprimé quand l'utilisateur déplace sa souris dans la page qui contient ce formulaire. Cette méthode admet que l'utilisateur a activé le Javascript sur son navigateur.
Après quelques mois d'utilisation, que peut-on en conclure ? Cette méthode fonctionne du feu de dieu ! Je suis passé à coté de plus de 50 milles commentaires indésirables. La crainte que j'avais se portait sur les supports mobiles : finalement, aucune inquiétude, ça fonctionne très bien sur les smartphones et les tablettes.
J'ai implanté cette solution sur un blog Wordpress et ça fonctionne très bien également...À croire que les développeurs de robots sont des manches.
Évidement, tout développement spécifique de robot va contrer cette sécurité, mais c'est assez rare finalement.
Cet article a été rédigé par Simon Vieille, développeur français animé par la culture du libre et du hacking.
Il intervient à Tinternet & Cie, une association d’éducation numérique populaire. Depuis septembre 2022, il est lead developer à Trinaps, un opérateur télécom local et indépendant.
Détecter les vulnérabilités dans les dépendances de son projet
La gestion des dépendances dans un projet est quelque chose de complexe. Il y a autant de ge…
Un an d'utilisation de AdGuard comme DNS
Au moment où j'ai commencé à utiliser Wireguard, je me suis aperçu que le principal usage qu…
Supprimer les mots de passe d'un fichier Excel
Dans le cadre de mon travail, je vais devoir supprimer les mots de passe définis dans plusie…
- Quid de l’accessibilité ? Par exemple pour un lecteur d'écran ? Et si je veux commenter sous un navigateur textuel ?
PS: Assez ennuyant la page qui mouline toutes les 2sec pour loguer des infos.
- Pour les lecteurs écran, je n'ai pas eu l'occasion de pouvoir tester. Si les logiciels sont capables de générer un événement javascript de mouvement de souris, ça fonctionnera. Pour les navigateurs en mode texte, c'est à priori mort. Cependant, une solution type captcha pose également problème (même si on peut utiliser par exemple fb-buffer pour afficher les images).
Ce n'est pas une solution miracle, elle est contraignante du fait qu'on soit obligé à utiliser javascript.
Pour le PS : je vais voir pour dégager la source du problème, ça me gave aussi !
- Pourquoi ne pas ajouter une question aléatoire triviale comme « Quelle est la couleur du cheval blanc d'Henri IV ? », « Quelle est la couleur du ciel bleu ? », voire des opérations comme « Conbien font deux plus trois ? (en chiffres) » ?
L’avantage, c'est que c'est accessible, et bien que les réponses soient automatisables (et encore, il faut vraiment le vouloir en testant toutes les questions), ça évite tous les bots anglophones.
- Ça fait partie des solutions oui. Maintenant, comment différencier une personne qui se trompe d'un robot ? Même si l'accessibilité pour les personnes aveugles (par exemple) est importante, la marge d'erreur sera nettement plus faible avec la méthode de l'article.
La question à se poser est la suivante : est-ce qu'un lecteur d'écran fonctionnera ? Je n'ai pas de quoi tester sous la main. Et vous ? Ça m'intéresse d'avoir la réponse en fait :)
- ben cela ne marhe pas
- Si si, sinon je serais ultra floodé et tu ne pourrais pas poste de commentare :)
- Excellente idée !
Juste question performance avec jQuery, tu pourrais exécuter la fonction une seule fois :
$(document).one('mousemove', function() {
var $form = $('#comment_form');
var action = $form.attr('action').replace(/^\/bot\?/, '');
$form.attr('action', action);
}
- Je n'avais pas connaissance de "one", c'est nickel =D Merci !
- J'ai mis à jour l'article initial, tu est évidement cité ;)
- Ne suffit-il pas de faire en sorte que le formulaire ne puisse être envoyé que via un appel de fonction ?
- Le javascript sera plus complexe et j'apprécie les hack simples. Demain, j'ai juste à virer "/bot?" pour désactiver ce système anti-flood.
- C'est dommage car cette solution réglerait le problème de l'accessibilité. Par ailleurs, je pense qu'il est aussi très simple de faire une solution qui demanderait une intervention minimale pour désactiver ce système anti-flood.
- Je n'ai peut-être pas tout compris alors. Cette fonction javascript, à part submit le formulaire (en gros : mon_form.submit()), elle fait quoi d'autres ?
- Elle ferait le "var action = $form.attr('action').replace(/^\/bot\?/, ''); $form.attr('action', action);" juste avant l'appel à la méthode submit.
- Ah ok. Le problème lié à cette méthode c'est que les bots qui embarquent javascript peuvent submit le formulaire en générant un event click (prévisible). L'intérêt (mais aussi ce qui peut bloquer les lecteurs d'écrans), c'est que c'est un évent de mouvement de souris qui traite le problème. Un robot intelligent va générer plein de choses sur la page, mais il ne "pensera" pas aux mouvements de souris.
Donc tu as raison sur le fait que ça puisse fonctionner, mais ça sera à mon avis moins efficace (mais plus accessible).
- Je serais vraiment curieux de savoir si les bots génèrent vraiment des évènements de click souris. Malheureusement (façon de parler) je n'ai pas de site subissant du spam pour le vérifier ;).
- J'ai déjà eu le cas de bot qui utilisaient un moteur de rendu gecko avec javascript. Sur un de mes services, j'utilisais une input type image pour soumettre le formulaire. La particularité de ce bouton c'est que les positions x ou y sont également envoyées et dans le cas de flood, elles n'étaient jamais nulles. Alors soit les robots étaient conçus pour générer des valeurs aléatoires, soit il y avait une action de "clique" sur ces boutons.
- Ok, c'est vraiment intéressant ! Après coup, je viens de me rappeler que certains bot de google génèrent aussi des clicks... En tout cas, merci pour ces infos :)
- Par exemple avec un navigateur textuel, on est considéré comme un robot.