D’accord, les amis, Pat Reeves ici, qui entre dans vos fils d’actualité depuis botsec.net. Nous sommes le 23 mars 2026, et j’ai été confronté récemment à un certain type de douleur de tête liée aux bots. Pas le genre sophistiqué sponsorisé par un État-nation – bien que ceux-là soient toujours amusants à disséquer – mais le désagrément automatisé légèrement trop intelligent qui cible l’un de mes projets annexes.
Pour donner un peu de contexte, mon projet annexe 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é sans bots. Jusqu’au mois dernier.
Soudain, des bots d’enregistrement. Pas seulement un filet, mais des vagues. Des centaines de faux comptes, tous avec des noms d’utilisateur légèrement randomisés, des adresses e-mail génériques (souvent provenant de domaines nouvellement enregistrés), et absolument aucune historique de posts. Ils ne spammaient pas immédiatement, ce qui était étrange. Ils se contentaient de… s’enregistrer. Et de remplir ma base de données utilisateurs, rendant sa gestion pénible et, franchement, me faisant sentir que mon petit havre numérique était envahi.
Donc, ce mois-ci, nous parlons de Vulnérabilité : La montée silencieuse – Pourquoi les inscriptions de bots à faible effort représentent une menace plus grande que vous ne le pensez (et comment les stopper).
L’ennui qui devient une menace
Vous pourriez penser, “Pat, ce ne sont que des inscriptions. Pas de quoi en faire un drame, n’est-ce pas ? Supprimez-les et passez à autre chose.” Et pendant un certain temps, c’était exactement mon raisonnement. J’ai mis en place un cron job pour purger les comptes sans posts après 24 heures. Problème résolu, non ? Faux.
Les bots se sont adaptés. Ils ont commencé à faire un seul, unique, post inoffensif. “Bonjour !” ou “Content d’être ici.” Rien qui ne déclencherait mes filtres anti-spam. Juste assez pour éviter la purge des comptes sans posts. Maintenant, j’avais des centaines de comptes avec un post inutile, toujours encombrant ma base de données, nécessitant encore une revue manuelle.
Ce n’est pas qu’un simple ennui. C’est une attaque subtile et insidieuse. Voici pourquoi :
- Épuisement des ressources : Chaque inscription, chaque entrée dans la 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 un désordre. Trouver de vrais utilisateurs, analyser l’activité, ou même simplement sauvegarder la base de données est devenu plus fastidieux.
- Risques pour la réputation : Si ces comptes se mettaient soudainement à spammer ou à pêcher à la ligne, la réputation de mon forum pourrait en souffrir. Les moteurs de recherche n’apprécient pas les sites associés à des activités malveillantes.
- Précurseur à des attaques plus importantes : Souvent, les bots d’inscription à faible effort sont une étape de reconnaissance. Ils testent les eaux, identifient les faiblesses, et établissent une base pour des attaques plus sophistiquées par la suite, comme le credential stuffing ou même le spear-phishing de vrais utilisateurs.
- Risques de Credential Stuffing et de Prise de Contrôle de Compte (ATO) : C’est le plus gros problème. Si un bot enregistre un compte, et qu’un utilisateur légitime essaie ensuite de s’inscrire 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 identifiants d’une autre violation. Il peut essayer ces identifiants sur mon site.
Donc, ce qui a commencé comme un problème “meh, je nettoierai ça plus tard” s’est rapidement transformé en une situation “cela doit s’arrêter maintenant”.
Mes premières (échouées) tentatives : Le piège CAPTCHA
Ma réaction initiale, comme beaucoup, a été de balancer un CAPTCHA. Spécifiquement, reCAPTCHA v2. Tout le monde connaît reCAPTCHA, n’est-ce pas ? 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 inscriptions ont chuté à presque zéro. Je me suis tapé dans le dos. “Aha ! Résolu !”
Puis, ils sont revenus. Pas autant, mais assez. Comment ? Eh bien, pour reCAPTCHA v2, il existe des services qui paient des humains en centimes pour résoudre des CAPTCHAs. Ou, de plus en plus, les modèles d’IA deviennent suffisamment performants pour les déchiffrer, surtout les plus simples. C’est un jeu du chat et de la souris, et sur un site à faible trafic, cela ne valait pas le coût de reCAPTCHA v3 (qui peut être un cauchemar à régler sans que des utilisateurs légitimes soient flaggés).
De plus, les utilisateurs légitimes détestent les CAPTCHAs. J’ai reçu quelques plaintes. Mon public passionné d’informatique rétro, Dieu les bénisse, n’est pas toujours le plus patient avec les désagréments du web moderne. J’avais besoin de quelque chose de moins intrusif, plus efficace contre les bots, et moins ennuyeux 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 fait d’un humain un humain, et d’un bot un bot, au-delà du simple fait de cliquer sur une case. Voici ce qui a vraiment 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, 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 "Échec de l'inscription. Veuillez réessayer.", 400 # Ou un message de succès générique pour embrouiller 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 au clavier vers celui-ci. autocomplete="off" aide à empêcher les navigateurs de le remplir 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, ce qui en fait un bon “appât”.
2. Analyse basée sur le temps (vérification de l’horodatage)
Les bots soumettent souvent des formulaires incroyablement rapidement. 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}, a pris {time_taken}s")
return "Échec de l'inscription. 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 capté une bonne partie des bots restants. Attention à ne pas rendre ce seuil trop élevé, car des utilisateurs authentiques pourraient taper rapidement ou avoir des formulaires préremplis.
3. Limitation de débit par IP (avec une touche)
La limitation standard du débit IP est bonne : “Pas plus de 5 inscriptions de cette IP par heure.” Mais les bots utilisent souvent des proxies ou font tourner les IP. Donc, 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 soudaine montée des inscriptions provenant de différentes IP mais avec la même chaîne User-Agent, légèrement inhabituelle, cela était un fort indicateur d’un botnet ou d’un seul bot faisant tourner les IP. Cela m’a permis de bloquer temporairement ou de flagger non seulement l’IP, mais aussi le User-Agent s’il était clairement non-browserve ou répété de manière suspecte.
Ce n’est pas un extrait de code que vous pouvez simplement glisser, car cela nécessite un certain enregistrement et une analyse côté backend. Mais conceptuellement, il s’agit de regarder les motifs au-delà de l’IP source. De nombreux pare-feu d’application web (WAF) offrent ce type de limitation avancée du débit et de détection d’anomalies.
4. Vérification du domaine d’email (en utilisant des données publiques)
De nombreuses inscriptions de bots proviennent de domaines d’email nouvellement enregistrés, souvent jetables. J’ai mis en place une vérification contre une petite liste sélectionnée de fournisseurs d’emails jetables connus, mais plus efficacement, j’ai commencé à regarder l’âge du domaine d’email lui-même.
Il existe des APIs (certaines payantes, d’autres gratuites avec des limites) qui peuvent vous indiquer quand un domaine a été enregistré. Si une adresse email provient d’un domaine enregistré dans les 30 derniers jours, c’est un énorme drapeau rouge. Ce n’est pas infaillible – de nouveaux sites légitimes se lancent tout le temps – mais combiné avec 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 que d’autres signaux de bot étaient présents (honeypot déclenché, soumission trop rapide), je bloquerais directement l’enregistrement. Pour les domaines de moins de 30 jours, je les signalerais pour une révision manuelle et exigerais potentiellement une confirmation par email avant l’activation.
Les Résultats : La 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 la majorité des enregistrements automatisés. L’analyse des modèles d’IP/User-Agent m’a aidé à identifier et à bloquer les opérateurs de bots les plus persistants.
Ma base de données utilisateurs est de nouveau propre. Mes journaux de serveur sont moins bruyants. Et je peux me concentrer sur la modération des discussions sur la supériorité du chipset SID du Commodore 64, 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 à faible coût m’ont redonné le contrôle de mon petit coin d’internet.
Points à Retenir
Si vous êtes confronté à des enregistrements de bots peu exigeants ou à des 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. Foncez.
- Ajoutez une Vérification Temporelle : Mesurez le temps entre le chargement du formulaire et la soumission. Bloquez les soumissions qui sont anormalement rapides.
- Allez au-delà du Simple Blocage d’IP : Recherchez des modèles dans les chaînes User-Agent, les référents et d’autres en-têtes de demande pour identifier des bots sophistiqués qui font tourner les IP. Considérez un WAF si votre trafic le justifie.
- Validez les Domaines des Emails : Vérifiez les fournisseurs d’emails jetables connus et considérez l’âge du domaine pour les nouveaux enregistrements.
- Surveillez et Adaptez : Les bots évoluent toujours. Gardez un œil sur vos journaux, analysez les activités suspectes et soyez prêts à ajuster vos défenses.
- Ne Dérangez Pas les Utilisateurs Réels : Priorisez l’expérience utilisateur. Évitez les CAPTCHAs trop contraignants ou les règles excessivement strictes qui pourraient bloquer des enregistrements légitimes. La meilleure défense contre les bots est celle que les humains ne remarquent même pas.
Restez prudents là-dehors, et gardez ces bots à distance !
Articles Connexes
- Exercices de l’équipe rouge contre les bots IA
- Architecture zéro confiance pour les bots IA
- Défense contre l’injection de prompt : erreurs courantes et solutions pratiques
🕒 Published: