Fermare il credential stuffing all'edge
Come tracio.ai identifica i tentativi di login automatizzati prima che raggiungano il sistema di autenticazione, combinando fingerprint del dispositivo, controlli di velocità e segnali comportamentali.
Gli attacchi di
credential stuffing
(riutilizzo massivo di credenziali rubate) usano strumenti automatizzati per testare combinazioni di username e password rubate contro le pagine di login. Gli attacchi sono massicci: un singolo operatore può testare milioni di credenziali al giorno su centinaia di siti bersaglio. Le difese tradizionali come il rate limiting e i CAPTCHA sono insufficienti perché gli aggressori distribuiscono le richieste su migliaia di indirizzi IP e usano servizi di risoluzione dei CAPTCHA. Ecco come fermiamo il credential stuffing all'edge, prima che le richieste raggiungano il suo sistema di autenticazione.
La superficie di attacco
Una tipica operazione di credential stuffing usa un elenco di credenziali rubate (disponibili sui marketplace del dark web per appena $10 per milione di record), uno strumento di automazione (di solito uno script personalizzato o un tool come OpenBullet) e un pool di IP proxy (proxy residenziali che ruotano a ogni richiesta per eludere il rate limiting basato su IP).
L'aggressore configura il proprio strumento per inviare richieste di login a un ritmo controllato — abbastanza lento da non far scattare i semplici limiti di frequenza, ma abbastanza veloce da testare migliaia di credenziali all'ora. Ogni richiesta proviene da un indirizzo IP diverso, con una stringa user agent diversa, in modo da sembrare un flusso di tentativi di login legittimi da parte di utenti diversi.
Perché il rate limiting fallisce
Il rate limiting basato su IP è la prima linea di difesa che la maggior parte dei team adotta, ed è la prima a cadere. I servizi di proxy residenziali danno accesso a milioni di indirizzi IP reali — router domestici, dispositivi mobili e dispositivi IoT — che ruotano a ogni richiesta. Dal punto di vista del server, ogni tentativo di login proviene da un IP residenziale unico, privo di uno storico di abusi.
Il rate limiting basato sull'account (limitare i tentativi di login per username) è più efficace ma crea un vettore di denial-of-service: un aggressore può bloccare gli utenti legittimi facendo deliberatamente fallire più tentativi di login contro i loro username.
Il fingerprinting del dispositivo come fondamento
Il fingerprinting del dispositivo cambia l'equazione perché identifica il dispositivo che esegue l'attacco, non l'IP che sta usando. Uno strumento di credential stuffing in esecuzione su una singola macchina o su una VM farm produce un fingerprint del dispositivo coerente su tutte le sue richieste, indipendentemente dall'IP proxy attraverso cui ruota.
Il nostro motore Bot Detection identifica gli strumenti di automazione stessi. Selenium lascia artefatti navigator.webdriver. Puppeteer e Playwright hanno caratteristiche distintive del runtime JavaScript. Headless Chrome manca di specifiche API del browser che il Chrome con interfaccia include. Persino i client HTTP personalizzati che non eseguono JavaScript vengono rilevati tramite il fingerprinting TLS: i loro messaggi Client Hello svelano la libreria HTTP sottostante.
Tracciamento della velocità per dispositivo
Una volta ottenuto un identificatore stabile del dispositivo (tramite Device Identification), possiamo applicare i controlli di velocità a livello di dispositivo anziché a livello di IP. Se un singolo dispositivo tenta 50 login in 5 minuti — indipendentemente da quanti IP diversi abbiano generato quelle richieste — il pattern è inequivocabilmente credential stuffing.
Il nostro modulo IP Intelligence traccia la velocità su tre finestre temporali: 5 minuti, 1 ora e 24 ore. Questo approccio multi-finestra intercetta sia gli attacchi aggressivi (centinaia di tentativi al minuto) sia gli attacchi lenti e a basso volume (pochi tentativi all'ora, protratti per giorni).
Analisi dei segnali comportamentali
Oltre al rilevamento dei bot e al tracciamento della velocità, la nostra analisi Smart Signals esamina i segnali comportamentali che distinguono gli attacchi automatizzati dai login legittimi. Gli utenti reali mostrano una variazione naturale nel timing delle richieste, nella velocità di digitazione e nei pattern di navigazione. Gli strumenti automatizzati tendono a produrre un timing meccanicamente costante, header di richiesta identici e nessun movimento del mouse o evento di scorrimento.
Verifichiamo anche le incoerenze dei segnali che indicano uno spoofing dell'ambiente. Un browser che dichiara di essere Chrome su macOS ma presenta parametri WebGL associati a una VM Linux viene segnalato immediatamente. Una stringa user agent che non corrisponde al fingerprint TLS attiva un avviso di manomissione.
Deployment all'edge
La chiave per fermare il credential stuffing è fermarlo prima che raggiunga il sistema di autenticazione. Il nostro agent si carica sulla pagina di login e raccoglie i segnali durante il caricamento della pagina — prima che l'utente (o il bot) invii le credenziali. I risultati del fingerprint e del rilevamento dei bot sono disponibili nel momento in cui il modulo di login viene inviato, consentendo al suo server di rifiutare all'istante i tentativi automatizzati.
Per i bersagli ad alto volume, consigliamo di distribuire la nostra integrazione Cloudflare Worker o CloudFront Lambda@Edge, che esegue la validazione del fingerprint all'edge della CDN. Questo significa che le richieste di credential stuffing vengono bloccate sul nodo edge più vicino all'aggressore, senza mai raggiungere i suoi server di origine.
Risultati
I nostri clienti segnalano una riduzione del 99% del volume di credential stuffing dopo aver distribuito tracio.ai sulle loro pagine di login. Il restante 1% è costituito da attacchi altamente sofisticati che usano l'automazione completa del browser con segnali accuratamente falsificati — che il nostro rilevamento multi-metodo intercetta nelle prime poche decine di richieste, man mano che emergono i pattern di velocità.