Coin web de Frédéric Péters

Contre les robots cons

14 février 2021, 12:20

C’était il y a quelques semaines, message de la personne en charge de l’adresse info@radiopanik.org, elle me dit que cette boite est submergée de messages d’erreur, me demande si je peux regarder; je m’exécute et ce que je constate c’est toute une série de rebonds, et même s’il y a une vague explication dedans, la lecture ne dépasse pas "This message was created automatically by mail delivery software." et quand il y en a comme ça des dizaines, c’est bien lourd.

Aparté : je sais qu’il y a peu de règles sur le contenu de ces messages mais quand même ça ne me paraitrait pas délirant qu’un programme grand public tâche de les interpréter pour présenter une version intelligible du problème, dans la langue de l’usager, façon « un message envoyé par info@radiopanik.org à l’adresse XX n’a pas pu arriver parce que la boite de l’usager était pleine / parce qu’il a été considéré comme spam / parce qu’il était trop gros / parce que le serveur n’accepte pas les connexions / etc. ». Clairement ça demande un travail de maintenance important mais à chercher rapidement je vois le projet Sisimai qui semble faire ça, avec une certaine finesse, jusqu’à l’interpération es codes d’hébergeurs français type laposte ou orange).

Bref je dégage les messages qui encombraient la boite, je réponds que ça  vient des abonnements à la newsletter, qu’il faut juste les ignorer pour le moment mais que je vais regarder si je peux bloquer ça.

Le système de newsletter de la radio est des plus classiques, un formulaire où mettre son adresse, l’envoi d’un message contenant un lien pour valider l’inscription, et c’est au clic sur le lien seulement que l’inscription devient effective. (techniquement à ce moment ça ajoute l’email dans une liste de discussion hébergée par domainepublic et la gestion future pour les envois, la gestion des rebonds et des désinscriptions est totalement déléguée à celle-ci).

Les rebonds venaient donc de tentatives d’inscription, avec une adresse invalide, et à regarder les logs c’était clairement de l’erreur automatisée, pas une personne se trompant en tapant son adresse, et c’était très grossier, avec une masse d’adresses tapées en majuscules, genre TRIUMPHTRUCKING@YAHOO.COM ou COCOFUNOCO@AOL.COM, d’autres avec quelques lettres en majuscule, genre Completepestmgmt@gmail.com ou ArtRosenbaumProperties@Gmail.com

En ne cherchant pas  à comprendre le sens de tout ça, misérable pollution du net, j’ai mis en place différentes choses, d’abord le log un peu plus détaillé de ces accès, enregistrement de l’adresse IP et de l’User Agent, pour voir si un sens pouvait en être tiré, si ça pouvait servir à bloquer certaines tentatives.

Résultat un peu moyen pour cette analyse : il y a des adresses de nœuds de sortie Tor mais pas uniquement, il y a des user agents bidons, mentionnant des versions terriblement datées, par exemple "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36" ou "Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0", mais ça serait une certaine galère à surveiller et maintenir, et trop facile d’y échapper.

Solution alternative alors, vieux truc qui semble totalement con : ajouter au formulaire un champ caché, vide. Et le robot élevé dans l’idée que remplir tous les champs augmente ses chances de validation réussie, il va le remplir.

<div style="display: none;">
<label><input type="checkbox" name="validation">Cocher empêchera la création.</label>
</div>

C’est hallucinant comme c’est effectif; par rapport au décompte des inscriptions légitimes, qui est d’une tous les quelques jours, voici le décompte des robots bloqués par cette vérification con :

    date     | count
-------------+-------
 2021-02-01  |    93
 2021-02-02  |   165
 2021-02-03  |   127
 2021-02-04  |   171
 2021-02-05  |   153
 2021-02-06  |    69
 2021-02-07  |    37
 2021-02-08  |    96
 2021-02-09  |   154
 2021-02-10  |   161
 2021-02-11  |   154
 2021-02-12  |   119
 2021-02-13  |    53

Je ne pensais pas que ça marcherait si bien et j’avais ajouté une précaution supplémentaire, level 2 anti-robots, un deuxième champ, là où le premier était une case à cocher à laisser vide, celui-ci est une case à cocher à remplir, ce que ferait pour l’humain un peu de javascript, sur l’idée qu’exécuter du javascript devient quelque chose de bien trop coûteux pour du robot aussi peu ciblé. C’est un peu nul parce qu’en dommage collatéral on trouvera les personnes qui désactiveraient le javascript, ce que je note dans le code :

<div style="display: none;">
  <label><input type="checkbox" name="validation2" 
id="validation2">Celle-ci doit par contre être cochée (déso les 
personnes sans js).</label>
  <script>
(function() {
  const checkbox = document.getElementById('validation2');
  checkbox.checked = true;
})();
  </script>
</div>

Est-ce que ça vaut la peine ? Résultats sur cette deuxième case à cocher ? Une seule personne prise dedans et j’ai même peur que ça soit une erreur (c’était le premier jour et je me dit qu’il restait peut-être en cache une version sans cette case), je ne recommenderais donc pas, c’est visiblement inutile pour le moment.