Pourquoi des CAPTCHA sur tous les sites ? Causes et solutions
Des CAPTCHA à répétition viennent presque toujours de votre route réseau, des réglages de votre navigateur, ou des deux qui se contredisent. Les causes par ordre de fréquence, avec une solution pour chacune.
Des CAPTCHA à répétition signifient généralement une seule chose. Quelque chose dans la manière dont vous arrivez sur un site ressemble à une machine, ou à une foule qui partage une même porte, et le site a relevé le coût d'entrée jusqu'à obtenir un signal plus clair. La vérification n'est que le symptôme. La cause se trouve dans votre route réseau, dans les réglages de votre navigateur, ou dans les deux qui racontent des histoires différentes au site.
Passez en revue les causes ci-dessous dans l'ordre. Les trois premières sont de loin les plus courantes, et elles ont toutes la même origine : l'adresse d'où part votre trafic.
Commencez par l'adresse, car c'est généralement elle
L'adresse est partagée, ou elle a un historique
La plupart des connexions ne vous donnent pas d'adresse bien à vous. Les opérateurs mobiles et de nombreux fournisseurs d'accès domestiques placent un grand nombre d'abonnés derrière un petit ensemble d'adresses publiques. Les bureaux, les campus et les espaces de coworking font de même. Ce que quelqu'un d'autre a fait derrière cette adresse ce matin, vous en héritez cet après-midi.
Les pools de proxys bon marché fonctionnent de la même façon, avec de moins bonnes chances. Un pool résidentiel partagé loue la même adresse à quiconque en achète à ce moment-là, et un site qui a vu une vague de tentatives de connexion depuis celle-ci se montrera prudent avec la suivante.
La solution commence par savoir quelle adresse vous présentez réellement, puis par la tester plutôt que de croire la description qu'on vous a vendue. Dans PowerOps, un proxy est ajouté à une bibliothèque et testé avant d'être approché d'un compte, et le test indique l'adresse observée. Si la route s'avère partagée, déplacez le profil vers une route qui ne l'est pas.
C'est une adresse de datacenter
Les plages d'adresses appartenant aux hébergeurs sont publiées, répertoriées et triviales à consulter. Une adresse de datacenter n'a rien de mal en soi, et énormément de trafic ordinaire en provient. Pour un compte grand public connecté, c'est en revanche un endroit inhabituel où se trouver, et les sites en tiennent compte.
La solution consiste à réserver les adresses de datacenter aux tâches sans connexion personnelle, et à utiliser des adresses résidentielles ou mobiles pour les sessions de compte. Le coût augmente. Les frictions diminuent. Tout l'arbitrage tient là.
Vous êtes sur une sortie VPN que tout le monde utilise
Un VPN grand public concentre un nombre énorme de personnes sur une poignée d'adresses de sortie. C'est le produit qui fonctionne comme prévu. C'est aussi pourquoi une session derrière un VPN accumule des vérifications qu'on ne rencontre nulle part ailleurs. Ce n'est pas votre comportement qui a mis cette adresse sous surveillance, c'est le volume.
La solution est une route propre à chaque profil, auprès d'un fournisseur qui vend des adresses persistantes. Si vous avez besoin d'un VPN pour autre chose, gardez-le éloigné de la machine ou du profil qui fait le travail sur les comptes, et ne l'empilez jamais sur un proxy.
L'adresse change au milieu d'une session
Les points d'accès à rotation vous attribuent une nouvelle adresse à chaque requête ou à intervalle régulier. Pour collecter des données publiques, c'est utile. Pour une session connectée, c'est un problème que vous vous créez vous-même. Une session qui démarre dans une ville et se poursuit depuis une autre quelques minutes plus tard décrit quelque chose qu'aucune personne ne fait.
Cette cause a une forme caractéristique. Les premières minutes se passent bien. Puis des vérifications apparaissent à chaque navigation, souvent avec une déconnexion surprise au milieu.
La solution est de passer le point d'accès en mode persistant (sticky) ou à session maintenue, avec une durée de conservation supérieure à votre session de travail. Attribuez la route avant la première connexion, car la première session est celle qui établit ce qui est normal pour ce compte.
Vérifiez ensuite que le navigateur raconte une histoire cohérente
Le fuseau horaire, la langue et l'adresse sont en désaccord
Un profil acheminé par Francfort qui annonce un fuseau horaire de Los Angeles a répondu à la même question de deux façons différentes. C'est aussi le cas d'un profil qui présente une adresse brésilienne avec une liste de langues du navigateur ne contenant que le vietnamien. Aucune de ces valeurs n'a rien de remarquable seule. Ensemble, elles forment la contradiction la moins chère à repérer pour un site.
La solution est de régler le fuseau horaire et la liste de langues du profil sur le pays où aboutit sa route, et de les vérifier ensemble après chaque changement de route. C'est la cause la plus fréquente de la liste qu'on s'inflige soi-même, et elle se corrige en une dizaine de secondes.
Le rythme des requêtes paraît automatisé
Des pages chargées à intervalles exacts de quatre secondes. Des formulaires remplis instantanément, sans aucun événement de focus entre les champs. Une navigation sans le moindre défilement. Une douzaine de profils qui font des choses identiques à la même seconde depuis le même sous-réseau. Rien de tout cela n'est interdit. Tout cela est inhabituel, et l'inhabituel est ce qui relève le coût d'entrée.
La solution est le rythme. Échelonnez les démarrages de profils au lieu de tout lancer d'un coup. Donnez aux tâches scriptées des délais variables et laissez les pages se stabiliser avant l'action suivante. Travaillez par lots plus petits. Si un script parcourt un site plus vite qu'une personne ne le pourrait, le site est en droit de demander qui se trouve de l'autre côté.
Examinez enfin ce que le navigateur conserve et ce qu'il bloque
Le jeu de cookies est périmé, absent, ou jeté chaque nuit
La plupart des vérifications enregistrent leur propre résultat. Une fois réussie, le site stocke de quoi dire que ce navigateur a déjà répondu, et la vérification cesse d'apparaître pendant un moment. Effacez les cookies à chaque fermeture, naviguez en fenêtre privée ou créez un profil temporaire neuf à chaque fois, et cette trace part à la poubelle à la fin de chaque session. La visite suivante repart de zéro.
La solution est un profil avec son propre répertoire persistant, fermé correctement pour que son état soit écrit sur le disque. Un profil tué en pleine session peut perdre la trace même qu'il venait de gagner.
Quelque chose bloque les scripts dont la vérification a besoin
Une vérification s'exécute sous forme de script, généralement chargé depuis un domaine appartenant au fournisseur de sécurité plutôt qu'au site que vous visitez. Les bloqueurs de contenu agressifs, les bloqueurs de scripts, les extensions de confidentialité renforcées et le stockage tiers désactivé peuvent tous empêcher ce chargement. La vérification ne se termine jamais, elle recommence donc. De votre côté, cela ressemble à une boucle infinie, ou à une boîte de défi qui tourne sans jamais se résoudre.
Procédez dans cet ordre :
- Ouvrez la même page dans un profil sans aucune extension. Si la boucle s'arrête, une extension est en cause.
- Réactivez les extensions une par une jusqu'à ce que le problème revienne. Les bloqueurs de contenu et les extensions de durcissement de la confidentialité sont les coupables habituels.
- Autorisez le domaine du fournisseur du défi dans l'outil qui le bloquait, plutôt que de désactiver entièrement le bloqueur.
- Vérifiez que JavaScript et le stockage tiers ne sont pas désactivés pour ce site.
- Vérifiez l'horloge du système. Une horloge décalée de plusieurs minutes casse les jetons signés dont dépend un défi, et la panne ne ressemble en rien à un problème d'horloge.
Du symptôme à la cause
Repérez ce que vous observez dans la colonne de gauche, et commencez par la solution de celle de droite.
| Ce que vous voyez | Cause la plus probable | Premier essai |
|---|---|---|
| Des vérifications sur tous les sites, dans tous les profils, dès la première requête | L'adresse elle-même : partagée, très sollicitée ou issue d'un datacenter | Testez la route et cherchez à qui appartient l'adresse |
| Un seul profil touché, les autres vont bien | La route de ce profil, ou son état stocké | Mettez une route que vous savez bonne avant de modifier quoi que ce soit d'autre |
| Tout va bien quelques minutes, puis des vérifications à chaque navigation | Un point d'accès à rotation qui change d'adresse en pleine session | Passez le point d'accès en mode persistant avec une longue durée de conservation |
| Vous réussissez une vérification et la même revient aussitôt | La réussite n'est pas enregistrée, ou un script nécessaire est bloqué | Cessez d'effacer les cookies à la fermeture, puis réessayez sans extensions |
| La boîte de défi tourne sans jamais se résoudre | Un bloqueur empêche le chargement du script du défi | Autorisez le domaine du fournisseur, puis vérifiez l'horloge du système |
| Le site s'affiche dans la mauvaise langue avant la connexion | La locale et la route sont en désaccord | Alignez la langue et le fuseau horaire du profil sur le pays de la route |
| Cela a commencé juste après un changement de proxy | L'historique du nouveau point d'accès | Testez le point d'accès et demandez-en un autre au fournisseur |
| Cela a commencé juste après la mise à jour d'une extension | L'extension | Désactivez-la pour ce site et rechargez |
Ce qu'il ne faut pas faire
Quelques réflexes aggravent la situation de façon fiable.
- Ne rendez pas l'identité du profil aléatoire pour vous débarrasser d'une vérification. Un appareil qui change à chaque visite est un signal plus bruyant que ce qui vous inquiétait, et il fait disparaître les preuves stockées de toutes les vérifications déjà réussies.
- N'effacez pas les cookies en première réaction. Ces cookies sont la trace des vérifications passées. Les effacer garantit que la visite suivante repart de rien.
- N'empilez pas un VPN sur un proxy. Vous obtenez deux routes en désaccord sur l'endroit où vous êtes, plus assez de latence supplémentaire pour que le rythme normal paraisse étrange.
- Ne martelez pas le bouton de rechargement. Les tentatives échouées répétées depuis une même adresse sont précisément le comportement que mesure une vérification.
- Ne déplacez pas un compte vers une toute nouvelle route en pleine session. Terminez la session, changez la route, puis reconnectez-vous.
Et une chose pour laquelle nous n'aiderons pas. Résoudre automatiquement ces vérifications dépasse ce que fait PowerOps et ce que ce blog expliquera. Des services qui le vendent existent. Nous ne nous y intégrons pas, nous ne les documentons pas, et rien dans le produit n'est conçu pour contourner une vérification de sécurité. Tout ce qui précède consiste à supprimer les raisons qu'a un site de poser la question. Répondre à votre place est un autre métier, et ce n'est pas le nôtre.
Si rien ne fonctionne
Parfois, la vérification n'a rien à voir avec vous. Un site attaqué relève son seuil pour tout le monde, et le trafic d'un pays entier peut se retrouver soumis à une règle plus stricte pendant un jour ou deux. Avant de passer un après-midi dessus, chargez la même page depuis une connexion ordinaire, sans proxy ni profil. Si la vérification vous y attend aussi, la réponse est d'attendre.
Le reste du temps, tout se résume à une courte liste. Une route avec un historique derrière elle. Une route qui ne tient pas en place. Des valeurs qui se contredisent. Un navigateur incapable de conserver ce qu'il a gagné. Corrigez ces quatre points et les vérifications redeviennent un désagrément occasionnel plutôt que le décor de votre journée de travail.
