Perché ricevo CAPTCHA su ogni sito? Cause e soluzioni
I CAPTCHA continui quasi sempre dipendono dal percorso di rete, dalle impostazioni del browser o dal fatto che i due raccontano storie diverse. Le cause in ordine di frequenza, con una soluzione per ciascuna.
I CAPTCHA continui di solito significano una cosa sola. Qualcosa nel modo in cui arrivi su un sito somiglia a una macchina, oppure a una folla che condivide un'unica porta, e il sito ha alzato il costo d'ingresso finché non riceve un segnale più chiaro. La verifica è il sintomo. La causa sta nel tuo percorso di rete, nelle impostazioni del browser, o in entrambi che raccontano al sito storie diverse.
Passa in rassegna le cause qui sotto in ordine. Le prime tre sono di gran lunga le più comuni e risiedono tutte nello stesso posto: l'indirizzo da cui arriva il tuo traffico.
Parti dall'indirizzo, perché di solito è quello
L'indirizzo è condiviso, o ha una storia alle spalle
La maggior parte delle connessioni non ti dà un indirizzo tutto tuo. Gli operatori mobili e molti provider domestici collocano un gran numero di abbonati dietro un piccolo gruppo di indirizzi pubblici. Uffici, campus e spazi di coworking fanno lo stesso. Qualunque cosa abbia fatto qualcun altro dietro quell'indirizzo stamattina, tu la erediti questo pomeriggio.
I pool di proxy economici funzionano allo stesso modo, con probabilità peggiori. Un pool residenziale condiviso affitta lo stesso indirizzo a chiunque lo compri in quell'ora, e un sito che ne ha visto in precedenza un'ondata di tentativi di accesso sarà prudente con il successivo.
La soluzione parte dallo scoprire quale indirizzo stai effettivamente presentando, poi dal testarlo anziché fidarti della descrizione che ti hanno venduto. In PowerOps un proxy viene aggiunto a una libreria e testato prima che si avvicini a un account, e il test riporta l'indirizzo osservato. Se il percorso risulta condiviso, sposta il profilo su uno che non lo sia.
È un indirizzo di datacenter
Gli intervalli di indirizzi appartenenti ai provider di hosting sono pubblici, catalogati e banali da consultare. Un indirizzo di datacenter non ha nulla di sbagliato in sé, e moltissimo traffico ordinario ne proviene. Per un account consumer con accesso effettuato, però, è un posto insolito in cui trovarsi, e i siti lo valutano di conseguenza.
La soluzione è riservare gli indirizzi di datacenter ai lavori che non richiedono alcun login personale e usare indirizzi residenziali o mobili per le sessioni degli account. Il costo sale. L'attrito scende. Questo compromesso è l'intera decisione.
Sei su un'uscita VPN che usano tutti
Una VPN consumer concentra un numero enorme di persone su pochissimi indirizzi di uscita. È il prodotto che funziona come progettato. È anche il motivo per cui una sessione dietro una di esse raccoglie verifiche che altrove non incontra. Non hai fatto nulla per mettere sotto esame quell'indirizzo. Lo ha fatto il puro volume.
La soluzione è un percorso dedicato per ogni profilo, da un provider che vende indirizzi sticky. Se ti serve una VPN per qualcosa di non correlato, tienila lontana dalla macchina o dal profilo che svolge il lavoro sugli account, e non sovrapporla mai a un proxy.
L'indirizzo cambia a metà sessione
Gli endpoint a rotazione ti assegnano un nuovo indirizzo a ogni richiesta o a ogni intervallo. Per raccogliere dati pubblici è utile. Per una sessione con accesso effettuato è un problema che ti crei da solo. Una sessione che inizia in una città e prosegue da un'altra pochi minuti dopo descrive qualcosa che nessuna persona fa.
Questa causa ha una forma inconfondibile. I primi minuti sono puliti. Poi le verifiche compaiono a ogni navigazione, spesso con una disconnessione a sorpresa nel mezzo.
La soluzione è passare l'endpoint a una modalità sticky o a sessione persistente, con un tempo di mantenimento superiore alla tua sessione di lavoro. Assegna il percorso prima del primo accesso, perché la prima sessione è quella che stabilisce che cosa è normale per quell'account.
Poi controlla se il browser racconta una storia coerente
Fuso orario, lingua e indirizzo non coincidono
Un profilo instradato attraverso Francoforte che dichiara un fuso orario di Los Angeles ha risposto alla stessa domanda in due modi diversi. Lo stesso vale per uno che presenta un indirizzo brasiliano insieme a un elenco di lingue del browser contenente solo il vietnamita. Nessuno dei due valori è notevole da solo. Insieme sono la contraddizione più economica che un sito possa cercare.
La soluzione è impostare il fuso orario e l'elenco delle lingue del profilo in modo che corrispondano al paese in cui approda il suo percorso, e controllarli insieme dopo ogni cambio di percorso. È la causa autoinflitta più comune dell'elenco e si corregge in circa dieci secondi.
Il ritmo delle richieste sembra automatizzato
Caricamenti di pagina a intervalli esatti di quattro secondi. Moduli compilati all'istante senza eventi di focus nel mezzo. Navigazione senza alcuno scorrimento. Una dozzina di profili che fanno cose identiche nello stesso secondo dalla stessa sottorete. Niente di tutto questo è vietato. È tutto insolito, e l'insolito è ciò che alza il costo d'ingresso.
La soluzione è il ritmo. Scagliona l'avvio dei profili invece di lanciare tutto insieme. Dai al lavoro automatizzato ritardi variabili e lascia che le pagine si assestino prima dell'azione successiva. Esegui lotti più piccoli. Se uno script si muove in un sito più velocemente di quanto potrebbe una persona, il sito ha il diritto di chiedere chi c'è dall'altra parte.
Poi guarda che cosa il browser conserva e che cosa blocca
Il set di cookie è obsoleto, assente o buttato via ogni notte
La maggior parte delle verifiche registra il proprio risultato. Ne superi una e il sito memorizza qualcosa che dice che questo browser ha già risposto, e la verifica smette di comparire per un po'. Cancella i cookie a ogni uscita, naviga in una finestra privata o crea ogni volta un nuovo profilo temporaneo, e quella traccia finisce nel cestino al termine di ogni sessione. La visita successiva parte a freddo.
La soluzione è un profilo con una propria directory persistente, chiuso correttamente in modo che il suo stato venga scritto. Un profilo terminato forzatamente a metà sessione può perdere proprio la traccia che aveva appena guadagnato.
Qualcosa blocca gli script di cui la verifica ha bisogno
Una verifica gira come script, di solito caricato da un dominio appartenente al fornitore di sicurezza anziché al sito che stai visitando. Content blocker aggressivi, blocker di script, estensioni per la privacy molto restrittive e l'archiviazione di terze parti disattivata possono tutti interrompere quel caricamento. La verifica non si completa mai, quindi riprova. Dal tuo lato sembra un ciclo infinito, o un riquadro di sfida che gira senza mai risolversi.
Procedi in quest'ordine:
- Apri la stessa pagina in un profilo senza alcuna estensione. Se il ciclo si ferma, la causa è un'estensione.
- Riattiva le estensioni una alla volta finché il problema ricompare. I content blocker e le estensioni di rafforzamento della privacy sono i soliti colpevoli.
- Consenti il dominio del fornitore della sfida in ciò che lo ha bloccato, anziché disattivare il blocker in blocco.
- Verifica che JavaScript e l'archiviazione di terze parti non siano disattivati per quel sito.
- Controlla l'orologio di sistema. Un orologio sfasato di diversi minuti rompe i token firmati da cui dipende una sfida, e il guasto non somiglia affatto a un problema di orologio.
Dal sintomo alla causa
Confronta ciò che vedi con la colonna di sinistra e parti dalla soluzione in quella di destra.
| Che cosa vedi | Causa più probabile | Prima cosa da provare |
|---|---|---|
| Verifiche su ogni sito, in ogni profilo, fin dalla prima richiesta | L'indirizzo stesso: condiviso, affollato o di datacenter | Testa il percorso e cerca a chi appartiene l'indirizzo |
| Un solo profilo colpito, gli altri a posto | Il percorso di quel profilo, o il suo stato memorizzato | Sostituisci con un percorso che sai essere buono prima di cambiare altro |
| Pulito per qualche minuto, poi verifiche a ogni navigazione | Un endpoint a rotazione che cambia indirizzo a metà sessione | Passa l'endpoint a una modalità sticky con un lungo tempo di mantenimento |
| Superi una verifica e la stessa ricompare subito | Il superamento non viene memorizzato, oppure uno script necessario è bloccato | Smetti di cancellare i cookie all'uscita, poi riprova senza estensioni |
| Il riquadro della sfida gira e non si risolve mai | Un blocker impedisce il caricamento dello script della sfida | Consenti il dominio del fornitore, poi controlla l'orologio di sistema |
| Il sito si carica nella lingua sbagliata prima dell'accesso | Impostazioni locali e percorso non coincidono | Fai corrispondere lingua e fuso orario del profilo al paese del percorso |
| È iniziato subito dopo un cambio di proxy | La storia del nuovo endpoint | Testa l'endpoint e chiedi al provider di fornirne un altro |
| È iniziato subito dopo l'aggiornamento di un'estensione | L'estensione | Disattivala per quel sito e ricarica |
Che cosa non fare
Alcuni riflessi peggiorano le cose in modo sicuro.
- Non randomizzare l'identità del profilo per scrollarti di dosso una verifica. Un dispositivo che cambia a ogni visita è un segnale più forte di qualunque cosa ti preoccupasse, e butta via le prove memorizzate di ogni verifica già superata.
- Non cancellare i cookie come prima reazione. Quei cookie sono la traccia dell'aver superato la verifica. Cancellarli garantisce che la visita successiva parta da zero.
- Non sovrapporre una VPN a un proxy. Ottieni due percorsi in disaccordo su dove ti trovi, più una latenza aggiuntiva sufficiente a far sembrare strane le tempistiche normali.
- Non martellare il ricaricamento. I ripetuti tentativi falliti dallo stesso indirizzo sono esattamente il comportamento che una verifica sta misurando.
- Non spostare un account su un percorso del tutto nuovo a metà sessione. Concludi la sessione, poi cambia il percorso, poi accedi di nuovo.
E una cosa su cui non aiuteremo. Risolvere automaticamente queste verifiche esula da ciò che fa PowerOps e da ciò che questo blog spiegherà. Esistono servizi che lo vendono. Non ci integriamo con essi, non li documentiamo, e nessuna parte del prodotto è costruita per aggirare un controllo di sicurezza. Tutto quanto sopra riguarda l'eliminazione dei motivi per cui un sito deve chiedere, in primo luogo. Rispondere alla domanda al posto tuo è un altro mestiere, e non è il nostro.
Se niente funziona
A volte la verifica non ha nulla a che fare con te. Un sito sotto attacco alza la soglia per tutti, e il traffico di un intero paese può trovarsi dietro una regola più severa per un giorno o due. Prima di passarci un pomeriggio, carica la stessa pagina da una connessione ordinaria, senza proxy e senza alcun profilo. Se la verifica ti aspetta anche lì, la risposta è aspettare.
Per il resto del tempo si riduce a una breve lista. Un percorso con una storia alle spalle. Un percorso che non sta fermo. Valori in disaccordo tra loro. Un browser che non riesce a conservare ciò che ha guadagnato. Sistema questi quattro punti e le verifiche tornano a essere un fastidio occasionale anziché la forma della tua giornata di lavoro.
