D’accord, les amis, Pat Reeves ici, intervenant dans vos fils d’actualité depuis botsec.net. Nous sommes le 23 mars 2026, et je me bats avec un type particulier de mal de tête lié aux bots dernièrement. Pas celui sophistiqué parrainé par un État-nation – même si ceux-ci sont toujours amusants à disséquer – mais le petit tracas automatisé, un peu trop intelligent, qui a ciblé l’un de mes projets annexes.
Mon projet annexe, pour donner un peu de contexte, est un petit forum de niche pour les passionnés d’informatique rétro. Rien de notable, juste un endroit pour nous, les vieux de la vieille, pour nous plaindre des CPU modernes et débattre de la meilleure façon d’émuler un Amiga. Le trafic n’est pas énorme, mais il est passionné, et pendant des mois, il a été délicieusement exempt de bots. Jusqu’au mois dernier.
Soudainement, des bots d’enregistrement. Pas juste un filet, mais des vagues. Des centaines de faux comptes, tous avec des noms d’utilisateur légèrement aléatoires, des adresses email génériques (souvent provenant de domaines récemment enregistrés), et absolument aucun historique de publication. Ils ne spammaient pas immédiatement, ce qui était la partie étrange. Ils se contentaient de… s’enregistrer. Et de remplir ma base de données d’utilisateurs, rendant la gestion pénible et, franchement, me faisant sentir que mon petit havre numérique était envahi.
Ainsi, ce mois-ci, nous parlons de Vulnérabilité : La Montée Silencieuse – Pourquoi les Enregistrements Autonome à Faible Effort Sont une Menace Plus Grande Que Vous Ne le Pensez (et Comment les Arrêter).
Le Désagrément Qui Devient une Menace
Vous pourriez penser, “Pat, ce ne sont que des enregistrements. Pas de quoi en faire un drame, non ? Supprimez-les et passez à autre chose.” Et pendant un temps, cela a été exactement mon état d’esprit. J’ai mis en place un job cron pour purger les comptes avec zéro post après 24 heures. Problème résolu, non ? Faux.
Les bots se sont adaptés. Ils ont commencé à faire un, seul, innocent post. “Bonjour !” ou “Content d’être ici.” Rien qui n’activerait mes filtres anti-spam. Juste assez pour éviter la purge à zéro post. Maintenant, j’avais des centaines de comptes avec un post inutile, encombrant toujours ma base de données, nécessitant encore des vérifications manuelles.
Ceci n’est pas juste un désagrément. C’est une attaque subtile et insidieuse. Voici pourquoi :
- Drain de Ressources : Chaque enregistrement, chaque entrée de base de données, chaque petit post consomme des ressources serveur. Pour un petit site comme le mien, ce n’est pas négligeable. Si le volume augmente, cela peut entraîner une dégradation des performances ou même un déni de service pour les utilisateurs légitimes.
- Pollution des Données : Mes tables d’utilisateurs étaient en désordre. Trouver des utilisateurs réels, analyser l’activité ou même juste sauvegarder la base de données est devenu plus compliqué.
- Risque de Réputation : Si ces comptes commençaient soudainement à faire du spam ou du phishing, la réputation de mon forum pourrait en pâtir. Les moteurs de recherche ne favorisent pas les sites associés à des activités malveillantes.
- Précurseur à de Plus Grands Attaques : Souvent, les bots d’inscription à faible effort sont une étape de reconnaissance. Ils testent les eaux, identifient des faiblesses, et construisent une base pour des attaques plus sophistiquées plus tard, comme le credential stuffing ou même le spear-phishing de vrais utilisateurs.
- Risque de Credential Stuffing & Prise de Contrôle de Compte (ATO) : C’est le gros problème. Si un bot enregistre un compte, et qu’un utilisateur légitime essaie plus tard de s’enregistrer avec le même nom d’utilisateur/email (ou un commun), l’opérateur du bot a maintenant une cible potentielle pour le credential stuffing s’il a acquis des crédentials d’une autre violation. Ils peuvent essayer ces crédentials contre mon site.
Ainsi, ce qui a commencé comme un problème de “meh, je vais le nettoyer plus tard” s’est rapidement transformé en “cela doit cesser maintenant”.
Mes Premières (Échecs) Tentatives : Le Piège CAPTCHA
Ma réaction initiale, comme beaucoup, a été de mettre un CAPTCHA. Plus précisément, reCAPTCHA v2. Tout le monde connaît reCAPTCHA, non ? La case à cocher “Je ne suis pas un robot”, peut-être quelques panneaux de signalisation flous.
Je l’ai mis en œuvre. Pendant environ trois jours, les enregistrements ont chuté à presque zéro. Je me suis félicité. “Aha ! Résolu !”
Puis, ils sont revenus. Pas autant, mais suffisamment. Comment ? Eh bien, pour reCAPTCHA v2, il existe des services qui paient des humains quelques centimes pour résoudre des CAPTCHAs. Ou, de plus en plus, des modèles d’IA deviennent suffisamment bons pour les déchiffrer, notamment les plus simples. C’est un jeu du chat et de la souris, et sur un site à faible trafic, cela ne valait pas le surcoût de reCAPTCHA v3 (qui peut être un cauchemar à ajuster sans que les utilisateurs légitimes ne soient signalés).
De plus, les utilisateurs légitimes DÉTESTENT les CAPTCHAs. J’ai reçu quelques plaintes. Mon public d’informatique rétro, qu’ils en soient remerciés, n’est pas toujours le plus patient face aux désagréments modernes du web. J’avais besoin de quelque chose de moins intrusif, plus efficace contre les bots, et moins agaçant pour les humains.
Au-delà de la Case à Cocher : Défenses Pratiques
Après avoir abandonné le CAPTCHA visible, j’ai commencé à réfléchir à ce qui rend un humain un humain, et un bot un bot, au-delà de simplement cocher une case. Voici ce qui a réellement fonctionné pour moi :
1. Le Champ Honeypot
C’est un classique pour une raison. C’est simple, efficace, et complètement invisible pour les utilisateurs humains. L’idée est d’ajouter un champ supplémentaire et caché à votre formulaire d’inscription. Les bots, étant moins sophistiqués que les humains, essaieront souvent de remplir chaque champ qu’ils trouvent. Les humains ne le verront pas, donc ils ne le rempliront pas.
Voici un exemple simplifié de ce que j’ai ajouté à mon formulaire d’inscription HTML :
<form action="/register" method="POST">
<label for="username">Nom d'utilisateur :</label>
<input type="text" id="username" name="username" required>
<label for="email">Email :</label>
<input type="email" id="email" name="email" required>
<!-- Champ honeypot -->
<div style="display:none;">
<label for="fax_number">Numéro de Fax (laisser vide) :</label>
<input type="text" id="fax_number" name="fax_number" tabindex="-1" autocomplete="off">
</div>
<label for="password">Mot de passe :</label>
<input type="password" id="password" name="password" required>
<button type="submit">S'inscrire</button>
</form>
Et du côté serveur (en utilisant un exemple Python/Flask, mais la logique s’applique universellement) :
@app.route('/register', methods=['POST'])
def register():
# Vérifier le champ honeypot
if request.form.get('fax_number'):
# Bot détecté ! Enregistrez-le, bloquez peut-être l'IP, et retournez une erreur
print(f"Honeypot déclenché par l'IP : {request.remote_addr}")
return "L'inscription a échoué. Veuillez réessayer.", 400 # Ou un message de succès générique pour troubler les bots
username = request.form.get('username')
email = request.form.get('email')
password = request.form.get('password')
# ... reste de votre logique d'inscription ...
return "Inscription réussie !"
Le display:none; le rend invisible. tabindex="-1" empêche la navigation clavier vers ce champ. autocomplete="off" aide à éviter que les navigateurs le remplissent automatiquement. J’ai choisi “fax_number” parce que c’est un champ à l’ancienne qui n’a pas sa place sur un formulaire d’inscription moderne, en faisant un bon “appât”.
2. Analyse Basée sur le Temps (Vérification de l’Horodatage)
Les bots soumettent souvent des formulaires à une vitesse incroyable. Les humains mettent au moins quelques secondes à remplir même un simple formulaire. J’enregistre le temps de chargement du formulaire et le temps de soumission.
Lorsque le formulaire d’inscription est servi :
<form action="/register" method="POST">
<!-- Autres champs du formulaire -->
<input type="hidden" name="form_load_time" value="{{ current_timestamp_in_seconds }}">
<button type="submit">S'inscrire</button>
</form>
Du côté serveur :
import time
@app.route('/register', methods=['POST'])
def register():
form_load_time = int(request.form.get('form_load_time', 0))
submission_time = int(time.time())
time_taken = submission_time - form_load_time
# Si le formulaire a été soumis trop rapidement (par exemple, moins de 5 secondes)
if time_taken < 5:
print(f"Soumission trop rapide par l'IP : {request.remote_addr}, durée {time_taken}s")
return "L'inscription a échoué. Veuillez réessayer.", 400
# ... reste de votre logique d'inscription ...
return "Inscription réussie !"
J’ai opté pour un minimum de 5 secondes. Cela a immédiatement attrapé une bonne partie des bots restants. Attention à ne pas rendre ce seuil trop élevé, car les utilisateurs sincères peuvent taper rapidement ou avoir des formulaires pré-remplis.
3. Limitation de Taux par IP (Avec une Touche)
La limitation standard par IP est bonne : “Pas plus de 5 inscriptions de cette IP par heure.” Mais les bots utilisent souvent des proxys ou changent d’IP. Alors, j’ai ajouté une touche : Empreinte IP et User-Agent.
J’ai commencé à enregistrer la chaîne User-Agent avec l’adresse IP. Si je voyais une hausse soudaine des inscriptions provenant de différentes IP mais avec la même chaîne User-Agent légèrement inhabituelle, c’était un fort indicateur d’un botnet ou d’un seul bot changeant d’IP. Cela m’a permis de bloquer ou de signaler temporairement non seulement l’IP, mais aussi le User-Agent s’il était clairement non-browser ou répété de manière suspecte.
Ceci n’est pas un extrait de code que vous pouvez simplement insérer, car cela nécessite un peu de journaling et d’analyse en backend. Mais conceptuellement, il s’agit d’examiner des modèles au-delà de juste l’IP source. De nombreux pare-feu d’application web (WAF) offrent ce genre de limitation de taux avancée et de détection d’anomalies.
4. Vérification de Domaine Email (en utilisant des Données Publiques)
De nombreux enregistrements de bots proviennent de domaines email nouvellement enregistrés, souvent jetables. J’ai mis en place une vérification contre une petite liste soigneusement sélectionnée de fournisseurs d’emails jetables connus, mais plus efficacement, j’ai commencé à examiner l’âge du domaine email lui-même.
Il existe des API (certaines payantes, d’autres gratuites avec des limites) qui peuvent vous indiquer quand un domaine a été enregistré. Si une adresse e-mail provient d’un domaine enregistré dans les 30 derniers jours, c’est un énorme signal d’alarme. Ce n’est pas infaillible – de nouveaux sites légitimes se lancent tout le temps – mais combiné à d’autres signaux, c’est puissant.
Pour mon forum, j’ai pris une décision pragmatique : si le domaine avait moins de 60 jours ET d’autres signaux de bot étaient présents (honeypot déclenché, soumission trop rapide), je bloquerais la création de compte. Pour les domaines âgés de moins de 30 jours, je les signalerais pour un examen manuel et exigerais éventuellement une confirmation par e-mail avant activation.
Les Résultats : Paix (Presque) Rétablie
La mise en œuvre de ces étapes n’a pas été une solution instantanée, mais elle a été incroyablement efficace. Le honeypot et les vérifications basées sur le temps ont immédiatement réduit le volume des inscriptions automatisées. L’analyse des motifs d’IP/User-Agent m’a aidé à identifier et bloquer les opérateurs de bots les plus persistants.
Ma base de données d’utilisateurs est à nouveau propre. Mes journaux de serveur sont moins bruyants. Et je peux me concentrer sur la modération des discussions sur la manière dont le chip SID du Commodore 64 était supérieur, au lieu de supprimer des centaines de faux comptes.
Il est important de comprendre que ce n’est pas une solution “à mettre en place et oublier”. Les bots évoluent. Les attaquants trouvent de nouvelles méthodes. Je devrai surveiller et m’adapter. Mais pour l’instant, ces méthodes pratiques et peu coûteuses m’ont redonné le contrôle de mon petit coin d’internet.
Conseils Actionnables
Si vous faites face à des inscriptions de bots peu élaborées ou à d’autres nuisances automatisées similaires, voici ce que vous devriez faire dès maintenant :
- Mettez en place un Honeypot : C’est incroyablement simple, efficace et invisible pour les utilisateurs. Faites-le.
- Ajoutez une Vérification Basée sur le Temps : Mesurez le temps entre le chargement du formulaire et la soumission. Bloquez les soumissions qui sont anormalement rapides.
- Allez au-delà du Blocage Simple par IP : Recherchez des motifs dans les chaînes User-Agent, les référents et d’autres en-têtes de requête pour identifier des bots sophistiqués changeant d’IP. Envisagez d’implémenter un WAF si votre trafic le justifie.
- Validez les Domaines Email : Vérifiez les fournisseurs d’e-mails jetables connus et considérez l’ancienneté du domaine pour les nouvelles inscriptions.
- Surveillez et Adaptez : Les bots évoluent toujours. Gardez un œil sur vos journaux, analysez l’activité suspecte et soyez prêt à ajuster vos défenses.
- Ne dérangez pas les Vrais Utilisateurs : Priorisez l’expérience utilisateur. Évitez les CAPTCHAs trop contraignants ou des règles trop strictes qui pourraient bloquer des inscriptions légitimes. La meilleure défense contre les bots est celle que les humains ne remarquent même pas.
Restez prudent, et gardez ces bots à distance !
Articles Connexes
- Exercices de l’équipe rouge de bots IA
- Architecture de zéro confiance pour bots IA
- Défense contre l’injection d’invite : erreurs courantes et solutions pratiques
🕒 Published: