Arrêter les bots avec Javascript

Résumé rapide

est une technique pratique pour arrêter le spam, mais elle est également inaccessible. En utilisant Javascript pour supprimer les attributs de formulaire critiques, le chargement dynamique du contenu du formulaire et le remplacement des boutons d’envoi peuvent être une alternative efficace qui maintient l’accessibilité de vos sites.

Auparavant, j’avais utilisé .NET MVC comme framework pour le site Web CANAXESS. Le formulaire de contact devait être accessible et ne pouvait compter sur aucun plugin qui nuirait à la capacité d’un utilisateur à nous contacter. Le formulaire avait un champ de formulaire caché CSS utilisant la technique honeypot et une logique côté serveur rejetant toutes les soumissions si le champ de formulaire contenait des données.

La théorie des robots ne peut pas comprendre ce qui est un champ légitime et ce qui ne l’est pas et le bot identifie et complète tous les champs de saisie et envoie le formulaire. Si le champ contient des données, nous supposons qu’en tant qu’utilisateur n’a pas pu accéder au champ de formulaire masqué, un utilisateur n’a pas soumis le formulaire et n’a pas supprimé toute l’entrée.

Les techniques de pot de miel sont toujours identifiées comme un moyen efficace d’arrêter les spams et pour moi, la technique a bien fonctionné pour réduire le spam à un niveau gérable par jour. Dans mon client de messagerie, je sélectionnerais tous les spams et les supprimerais en masse, tous assez simples si cela prend du temps.

Passage à Netlify #

Dans le cadre de l’évolution de l’infrastructure, le site Web de CANAXESS a été déplacé vers Netlify, ce qui signifiait que la technique de filtrage du spam existante devait être repensée, car le site précédent était construit en .NET et hébergé dans un environnement .NET.

Au départ, j’ai choisi de ne pas utiliser de protection anti-spam et de voir comment cela s’est passé. Comme on pouvait s’y attendre, les messages de spam sont venus épais et rapides.

Utilisation d’un honeypot #

Netlify fournit une fonctionnalité de honeypot qui suit la même technique d’utilisation d’un champ de saisie caché et si cela est prérempli, tous les e-mails sont envoyés dans le dossier spam.

<form name="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">
<input class="actual-hidden" name="bot-field" tabindex="-1">

La technique a fonctionné très efficacement; aucun e-mail légitime n’a jamais atteint le dossier d’e-mail normal.

Mais le dossier spam racontait une autre histoire. Il y avait des pages de résultats de spam, où auparavant je pouvais sélectionner tous les e-mails en masse et les supprimer, l’approche Netlify signifiait que seuls les e-mails 10-20 étaient renvoyés à la fois, la pagination étant utilisée pour passer aux dix prochains e-mails. Il n’y avait pas de fonctionnalité de suppression de masse et j’ai dû supprimer des fonctionnalités individuelles.

Cela prenait énormément de temps et était fastidieux. J’ai écrit un bookmarklet Javascript qui, j’espérais, faciliterait la vérification de tous les contrôles de case à cocher sur la page et la suppression de tous les enregistrements.

Malheureusement, la logique de page ne reconnaissait pas mon bookmarklet comme ayant interagi physiquement avec chaque contrôle et ne permettait pas la sélection de tous les e-mails en masse.

Je ne pouvais pas non plus être sûr si des e-mails dans le dossier spam étaient des faux positifs – des e-mails mal identifiés, ce qui signifiait que je devais parcourir tous les e-mails pour confirmer.

Actualisation re #

Netlify fournit Google re et j’ai initialement envisagé son utilisation car les e-mails augmentaient quotidiennement.

Cependant, la perception d’une entreprise d’accessibilité Web utilisant une méthode connue inaccessible pour que les gens les contactent n’était pas une bonne idée.

J’ai déjà écrit à quel point une technique est terrible pour saper l’accessibilité d’un site Web et j’ai pensé que si je ne pouvais pas résoudre ce problème, quel espoir y a-t-il pour les autres.

J’ai décidé de programmer mon moyen de m’en sortir.

Rendre le formulaire moins attrayant pour les bots #

J’avais besoin de faire en sorte que le formulaire de contact ressemble moins à un formulaire de contact et soit moins attrayant pour les bots. J’ai commencé à supprimer l’attribut method sur l’élément de formulaire. S’il n’y a pas d’attribut method, j’ai pensé que le formulaire ne pouvait pas être envoyé.

<form name="contactSubmission" data-netlify="true" 
netlify-honeypot="bot-field">

Malheureusement, même si l’attribut a été supprimé, Netlify a appliqué l’attribut de méthode sur le formulaire au fur et à mesure du déploiement du site et c’était quelque chose que je ne pouvais pas contrôler.

<form name="contactSubmission" method="post">

En utilisant jQuery pour supprimer un attribut #

J’ai décidé d’utiliser Javascript (jQuery) pour supprimer dynamiquement l’attribut method après le chargement de la page. À l’aide de l’événement jQuery ready, l’élément de formulaire est sélectionné et l’attribut method est supprimé.

$(function(){
$("#contactSubmission").removeAttr("method");
});

J’ai ensuite demandé un moyen d’ajouter l’attribut à l’élément de formulaire avant l’envoi. J’ai dû l’ajouter dans une séquence pour m’assurer que l’attribut existe avant l’envoi du formulaire, sinon le formulaire s’effacera et l’utilisateur rencontrera un formulaire de contact cassé, ce qui n’est pas idéal!

Remplacement du bouton d’envoi #

De plus, j’avais décidé de supprimer également le bouton submit. Déterminer s’il n’y avait pas de bouton submit, le formulaire ne peut pas être soumis via un navigateur sans tête (si les spammeurs utilisaient cette technique) car il ressemble moins à un formulaire de contact et plus à une collection de champs de saisie.La soumission du formulaire

aurait lieu via un élément button régulier uniquement par programmation.

<input type="button" value="Contact CANAXESS" 
class="contactForm-button submit">

Ajout de l’attribut de méthode lors de la soumission #

Le bouton normal avait un gestionnaire d’événements click qui ajoutait l’attribut de méthode et la valeur à l’élément de formulaire.

Lorsque vous cliquez sur le bouton, l’attribut est ajouté, mais il peut y avoir des cas où la synchronisation des éléments de script se produit contrairement à ce que je voulais.

Pour surmonter cela, j’ai ajouté un intervalle de minuterie. Cela vérifie à plusieurs reprises l’élément de formulaire pour l’attribut method toutes les 100 millisecondes, si aucun attribut method n’existe, le formulaire n’est pas soumis.

$("input.contactForm-button").click(function(){
$("#contactSubmission").attr("method", "post");
var checkExist = setInterval(function(){ 
var attr = $("#contactSubmission").attr("method");
if (typeof attr !== typeof undefined && attr !== false)
{
$("#contactSubmission").submit();
clearInterval(checkExist);
}
}, 100);
});

La soumission du formulaire ne se produit que lorsque l’attribut method existe, et cela se produirait par programme. Lorsque le formulaire avait été soumis, le minuteur d’intervalle prenait fin.

clearInterval(checkExist);

Je pensais que c’était un moyen assez efficace de sur-concevoir un formulaire de contact pour arrêter les robots, mais ma confiance ne devait pas durer. Je suis revenu quelques heures plus tard pour retrouver les spams collectés.

La soumission du formulaire se fait via HTTP #

Et puis il m’est apparu, les bots ne visitent probablement même pas la page via le navigateur, ils ne se soucient pas de tout le script jQuery qui s’exécute côté client en supprimant des éléments.

L’attribut method existe lorsque la page est chargée, et à partir de là, il s’agit d’un simple grattage du code HTML et de la soumission du formulaire via un post HTTP sans jamais interagir avec la page.

Et c’est cette prise de conscience qui m’a ensuite fait identifier la technique qui permettrait non seulement de ralentir les spams mais de les arrêter. Depuis l’application de cette technique, je n’ai eu aucun e-mail, aucun, zilch.

Séparation de la page du formulaire #

La technique charge le fragment de formulaire via Javascript après le chargement de la page. Réalisant que les robots spammeurs n’utilisent probablement pas un navigateur sans tête pour naviguer sur la page de contact et soumettre le formulaire, j’ai plutôt fait apparaître le formulaire uniquement lorsque la page a été chargée à partir d’un navigateur.

La page de contact rendue dans le navigateur est une page, mais est en réalité composée de deux parties. La page principale avec un espace réservé pour le composant de formulaire et le contenu du formulaire lui-même.

<div></div>

Chargement du formulaire sur la page load #

Lorsque la page est chargée, un événement jQuery ready charge le fragment de formulaire supplémentaire dans le conteneur de formulaire DIV presque immédiatement.

La page de fragment de formulaire n’est jamais identifiée par un bot car la page initiale que le bot voit n’a aucun élément de formulaire, elle n’est chargée qu’après le chargement de la page via Javascript.

<script>
$(function(){
$("#formContainer").load("formfragment.html");
});
</script>

En résumé #

La technique nécessite Javascript pour fonctionner. Comme Javascript est devenu une partie acceptée du développement Web, je pense que c’est une solution réaliste pour arrêter le spam dans certaines situations spécifiques.

L’autre technique d’utilisation des champs de pot de miel est toujours problématique car d’après mon expérience, elle n’était pas si efficace.

Le spam trouverait toujours un moyen de passer et si je suis honnête, la technique du pot de miel ne peut être classée que comme un limiteur de spam, réduisant les instances de spam.

Alors que l’utilisation fonctionnerait et serait une solution rapide, son utilisation mine de rendre le Web accessible aux personnes handicapées.

En supprimant le rendu du formulaire de contact dans le cadre d’une requête HTTP get régulière, sa visibilité sur les robots semble être considérablement réduite et, par conséquent, réduit (et dans mon cas, a cessé) les robots de pouvoir soumettre du spam via le formulaire de contact.

Choses à essayer #

Quel que soit le cadre utilisé par votre site, si votre formulaire de contact est compromis par du spam, essayez ces approches:

• Séparez la page et le formulaire
• Chargez le formulaire après le chargement de la page
• Soumettez uniquement les formulaires par programme en utilisant button éléments
• Supprimez l’attribut method sur les formulaires et ajoutez-les dans le cadre de la soumission du formulaire