Login
Prova gratuita

Come prevenire l'abuso della reimpostazione della password nel vostro sito web (2026)

Illustrazione sulla prevenzione dell'abuso della reimpostazione della password, mostrando minacce come gli attacchi automatici, l'enumerazione degli utenti, l'e-mail flooding e il credential stuffing insieme a protezioni come la limitazione del tasso, la verifica CAPTCHA, la protezione dell'esistenza dell'account e gli avvisi di monitoraggio.
captcha.eu

La maggior parte dei team protegge attentamente la propria pagina di login e lascia il flusso di reimpostazione della password quasi aperto. Gli aggressori lo sanno. Utilizzano il flusso di reimpostazione per enumerare gli account validi, inondare le caselle di posta elettronica con e-mail automatiche, rubare i token attraverso la generazione di link deboli e aggirare le protezioni di login che avete dedicato a indurire. Questa guida spiega tutti gli schemi di abuso della reimpostazione e i passi pratici per fermarli.

Tempo di lettura stimato: 13 minuti

Prova CAPTCHA.eu gratuitamente - senza carta di credito
Visualizza tutte le integrazioni

In sintesi

Perché i flussi di reset vengono abusati

Il flusso di ripristino bypassa completamente la pagina di login. Se è più debole del login, gli aggressori la usano come via più facile per accedere all'account.

Quattro modelli di abuso da conoscere

Enumerazione degli account, reset flooding, furto di token e progettazione di recuperi deboli. Ognuno di essi necessita di una difesa diversa e nessuno di essi può essere risolto con la sola protezione del login.

La correzione singola più veloce

Restituire la stessa risposta indipendentemente dall'esistenza o meno di un conto. Questa singola modifica elimina l'enumerazione dei conti a costo zero.

Cosa tratta questa guida

Perché i flussi di reset delle password vengono presi di mira

Il flusso di reimpostazione della password è la porta di servizio del sistema di autenticazione. Il suo compito è quello di far rientrare gli utenti senza la loro password, il che significa che deve bypassare il normale controllo delle credenziali. Questo lo rende strutturalmente più debole del login e gli aggressori sfruttano direttamente questa lacuna.

Tre fattori rendono i flussi di reset obiettivi interessanti. In primo luogo, la maggior parte dei team aggiunge una forte protezione bot al login, ma trascura completamente l'endpoint di reset. In secondo luogo, i flussi di reset rivelano informazioni utili agli aggressori: se un account esiste, quali indirizzi e-mail sono registrati e quanto rapidamente scadono i token di reset. In terzo luogo, i moduli di reimpostazione sono rivolti al pubblico e facili da automatizzare: un bot può attivare migliaia di richieste di reimpostazione all'ora contro un modulo senza limitazione del tasso o CAPTCHA.

Il risultato è che anche i team che hanno rafforzato il login, aggiunto l'MFA e implementato il rate limiting spesso lasciano la reimpostazione della password come un'entrata secondaria non protetta. Il Forgot Password Cheat Sheet di OWASP elenca le vulnerabilità del flusso di reset tra le debolezze di autenticazione più comunemente sfruttate nelle applicazioni di produzione. Il punto più debole del vostro sistema di autenticazione è l'unico che conta per un attaccante determinato, e se questo punto è il modulo di reimpostazione, tutta la protezione della pagina di login non conta nulla.

I quattro modelli di abuso della reimpostazione della password

L'abuso della reimpostazione della password non è un singolo tipo di attacco. Si tratta di una categoria di quattro modelli distinti, ciascuno con obiettivi diversi e difese diverse.

SCHEMA DI ABUSO
COSA FANNO GLI AGGRESSORI
COSA GUADAGNANO
Enumerazione dei conti
Inviare richieste di reset per molti indirizzi e-mail e osservare se le risposte differiscono per gli account esistenti rispetto a quelli non esistenti.
Un elenco convalidato di indirizzi e-mail di account reali da utilizzare per phishing, credential stuffing o attacchi mirati.
Ripristino dell'allagamento
Attivare automaticamente un gran numero di e-mail di ripristino per uno o più account.
Sovraccarico della posta in arrivo che nasconde e-mail di phishing, molestie agli utenti o degrado della reputazione dell'infrastruttura di posta.
Furto di token e forza bruta
Intercettare i link reimpostati attraverso le intestazioni dei referrer, gli URL archiviati o la cronologia del browser; oppure forzare brutalmente i token brevi/prevedibili.
Token di reset valido che consente di impostare una nuova password e di assumere il controllo dell'account senza conoscere quella originale.
Design di recupero debole
Sfruttare metodi di recupero non sicuri: token riutilizzabili, link non scadenti, domande di sicurezza con risposte indovinabili o scambio di SIM per intercettare i codici SMS
Accesso all'account attraverso il percorso di recupero senza dover interrompere il flusso di login

Questi quattro schemi spesso compaiono insieme in un'unica campagna di attacco. Un aggressore può iniziare con l'enumerazione per identificare gli account reali, quindi utilizzare il reset flooding per creare confusione mentre esegue un furto di token o uno scambio di SIM contro un obiettivo specifico di alto valore. Per difendersi da tutti e quattro gli attacchi sono necessari controlli a più livelli, non un'unica soluzione.

Sette difese che funzionano

  • Restituire risposte coerenti per i conti esistenti e per quelli non esistenti

    Questa è la modifica più importante che si possa fare e non costa quasi nulla da implementare. Quando un utente invia una richiesta di reset per un indirizzo e-mail, restituite esattamente lo stesso messaggio, lo stesso codice di stato HTTP e lo stesso tempo di risposta, sia che l'account esista o meno. Un messaggio come “Se esiste un account con quell'indirizzo, riceverete un'e-mail di reset” chiude completamente l'enumerazione degli account. L'errore comune è quello di restituire “Ti abbiamo inviato un'e-mail di reset” per gli account reali e “Nessun account trovato” per quelli inesistenti. Il Forgot Password Cheat Sheet di OWASP segnala specificamente questo schema come una delle vulnerabilità di enumerazione più diffuse nelle applicazioni di produzione. Correggete il testo della risposta, ma controllate anche la tempistica della risposta: se la vostra applicazione interroga il database prima di restituire una risposta, la differenza di tempo tra un account reale trovato e uno non trovato può essa stessa far trapelare informazioni. Utilizzate un'elaborazione asincrona o un ritardo artificiale per rendere coerenti i tempi.

  • Aggiungere CAPTCHA al modulo di richiesta di ripristino

    Il CAPTCHA nel modulo di reimpostazione blocca due modelli di abuso in un colpo solo: l'inondazione di reimpostazione e l'enumerazione di account su scala. Un aggressore che verifica migliaia di indirizzi e-mail per trovare account validi deve automatizzare tali richieste. Un CAPTCHA proof-of-work costringe a un calcolo crittografico per ogni invio, rendendo l'automazione su larga scala economicamente impraticabile senza influenzare gli utenti legittimi che inviano una richiesta alla volta. Per i siti web europei, la scelta del CAPTCHA è più importante che altrove. Il modulo di reset è una pagina critica per la sicurezza in cui gli utenti si trovano già in una condizione di vulnerabilità: hanno perso l'accesso al proprio account. L'aggiunta di un CAPTCHA comportamentale basato sui cookie introduce domande sul consenso alla privacy proprio nel momento sbagliato. Un CAPTCHA proof-of-work senza cookie si integra senza richiedere ulteriori avvisi di consenso nelle pagine di recupero. Per una spiegazione completa di come funziona, consultate la nostra guida su cosa sono i CAPTCHA invisibili.

Proteggere il flusso di reimpostazione della password senza cookie o consenso in testa

CAPTCHA.eu blocca il reset flooding e l'enumerazione su scala con la verifica invisibile proof-of-work. Senza cookie, ospitato in Austria, certificato WCAG 2.2 AA dal TÜV Austria.

Iniziare la prova gratuita
Vedi tutte le integrazioni

    • Applicare la limitazione della velocità per account e per IP

      La limitazione della velocità sull'endpoint di ripristino limita il volume degli abusi anche quando il CAPTCHA è già attivo. Applicate limiti a due livelli: per indirizzo IP e per account. La limitazione a livello di IP rallenta un attaccante che utilizza un numero ridotto di indirizzi. La limitazione a livello di account garantisce che anche un attacco distribuito non possa inondare ripetutamente una singola casella di posta. Una soglia iniziale ragionevole è di tre-cinque richieste di ripristino per account all'ora. Dopo questo limite, rifiutate le nuove richieste in modo silenzioso: restituite la stessa risposta coerente senza inviare una nuova e-mail. Non dite all'utente che ha raggiunto un limite di velocità, perché questo fa trapelare informazioni sulla vostra logica di limitazione della velocità. Applicate limiti anche all'endpoint di convalida dei token: un aggressore che tenta di forzare brutalmente un token di reset deve inviare molti tentativi di token, e la limitazione della velocità di questo endpoint elimina completamente la superficie di attacco per i token brevi.

    • Utilizzare token crittograficamente forti, di breve durata e monouso.

      I token di ripristino sono le chiavi degli account degli utenti. Generateli con un generatore di numeri casuali crittograficamente sicuro, non un timestamp, non un ID sequenziale, non un hash di input prevedibili. Il NIST SP 800-63B raccomanda almeno 20 byte di entropia per i segreti di ripristino, che si traduce in un token di almeno 40 caratteri esadecimali o una codifica base64 equivalente. Impostate una scadenza breve: un'ora è generosa per la maggior parte delle applicazioni; 15-30 minuti sono appropriati per contesti di maggiore sicurezza. Fate scadere il token subito dopo il suo utilizzo: un token che rimane valido dopo la reimpostazione della password è una backdoor persistente. Fate scadere anche tutti gli altri token attivi per quell'account quando viene richiesto un nuovo reset: se un aggressore attiva un nuovo reset dopo che l'utente ne ha già ricevuto uno, il vecchio token non dovrebbe più funzionare.

    • Prevenire la perdita di token attraverso le intestazioni dei referrer e la cache

      I token di ripristino forniti negli URL corrono un rischio specifico: il token può trapelare attraverso l'intestazione HTTP Referrer se la pagina di ripristino contiene risorse esterne (script di analisi, font, risorse CDN o immagini di terze parti). Quando un utente fa clic su un link della pagina di ripristino, il browser può inviare l'URL completo (compreso il token) come Referrer a server esterni. Per evitare che ciò accada, impostate Referrer-Policy: no-referrer nella pagina di conferma del reset. Impostate anche intestazioni cache-control appropriate per evitare che gli URL di reset vengano memorizzati nella cronologia del browser o nelle cache dei proxy. Indicate all'applicazione di non registrare i valori dei token di reset nei log degli accessi o nei sistemi di tracciamento degli errori, poiché questi sono una fonte comune di esposizione involontaria dei token negli ambienti di produzione.

    • Sostituire le domande di sicurezza con canali secondari verificati

      Le domande di sicurezza non sono un metodo di recupero sicuro. Le risposte alle domande di sicurezza più comuni (nome da nubile della madre, animale domestico d'infanzia, prima scuola) sono spesso disponibili pubblicamente attraverso i social media, i broker di dati o ricerche mirate. Forniscono l'apparenza di una verifica senza la sostanza. Sostituite le domande di sicurezza con canali secondari verificati: e-mail a un indirizzo confermato al momento della registrazione o codici TOTP basati su app. Se il recupero tramite SMS è inevitabile, è bene sapere che lo scambio di SIM lo rende vulnerabile per i conti di alto valore. Per gli account in cui la posta in gioco è alta (accesso all'amministratore, credenziali di pagamento, cartelle cliniche), richiedere un secondo canale verificato piuttosto che un unico percorso di recupero.

    • Notificare agli utenti e monitorare i modelli di reset anomali.

      Inviare agli utenti una notifica quando viene richiesto un reset, non solo quando viene completato. Un messaggio del tipo “È stato richiesto un reset della password per il tuo account. Se non sei tu, puoi ignorare questa e-mail - la tua password non è cambiata” dà agli utenti la possibilità di reagire prima che un aggressore utilizzi un token rubato. Sul fronte del monitoraggio, un picco improvviso di richieste di reset è un segnale precoce di una campagna di enumerazione o di flooding. Impostate avvisi per volumi insoliti di reset per IP, per account o per l'intera applicazione. Correlare i picchi di reset con i modelli di fallimento del login: gli aggressori spesso testano gli account enumerati nella pagina di login prima di passare al flusso di reset quando incontrano il rate limiting o il CAPTCHA.

    La postura di sicurezza minima ripristinabile

    Se si implementano solo tre cose: risposte coerenti (Difesa 1), CAPTCHA nel modulo di reset (Difesa 2) e token monouso di breve durata (Difesa 4), si chiudono le vulnerabilità di reset più comunemente sfruttate. Aggiungete gli altri progressivamente in base alla sensibilità degli account che proteggete.

    Dove si inserisce il CAPTCHA nella protezione della reimpostazione delle password

    Il CAPTCHA nel modulo di reimpostazione della password ha un ruolo specifico e limitato: impedisce l'abuso automatico dell'endpoint di reimpostazione. Impedisce ai bot di verificare la validità di migliaia di indirizzi e-mail e impedisce l'inondazione automatica di reset contro utenti specifici. Non risolve la debolezza della generazione del token, non previene la fuga di token attraverso le intestazioni dei referrer e non sostituisce la progettazione di risposte coerenti.

    Questo posizionamento è importante perché alcuni team fanno eccessivo affidamento sul CAPTCHA (usandolo come unico controllo) o lo usano poco (saltandolo perché “gli utenti non devono risolvere un puzzle per reimpostare la password”). Entrambi non colgono il punto. Il CAPTCHA invisibile non aggiunge alcun attrito visibile per gli utenti legittimi che inviano una richiesta di reset. Aumenta solo il costo per i bot che ne inviano migliaia. È proprio questa la posizione del CAPTCHA nel sistema di difesa.

    Per il flusso di ripristino di WordPress, in particolare, il nostro Guida al CAPTCHA di WordPress copre l'integrazione a livello di wp-login.php. Per Keycloak, il flusso di reimpostazione delle credenziali richiede uno snippet FTL separato dai flussi di login e di registrazione: il nostro Guida all'integrazione di Keycloak copre tutti e tre i flussi con passaggi di configurazione specifici.

    Abuso della reimpostazione della password e obblighi del GDPR

    Un attacco di reimpostazione della password andato a buon fine e che comporta l'accesso non autorizzato all'account costituisce una violazione dei dati personali ai sensi del GDPR. Se l'account compromesso conteneva dati personali (come quasi tutti gli account utente), dovrete affrontare gli obblighi di valutazione e notifica di cui all'articolo 33.

    C'è anche un aspetto specifico del GDPR nel modulo di ripristino stesso. I servizi CAPTCHA tradizionali che impostano i cookie sulle pagine di ripristino creano un requisito di consenso ePrivacy in un momento scomodo: un utente che ha perso l'accesso al proprio account deve ora navigare in un banner di consenso ai cookie prima di recuperarlo. Un CAPTCHA proof-of-work senza cookie elimina questo problema dal punto di vista strutturale. Non è necessario alcun meccanismo di consenso per il livello CAPTCHA stesso, il che rappresenta una significativa semplificazione della conformità per i DPO che gestiscono l'onere della documentazione dei flussi di autenticazione.

    L'angolo dell'articolo 32

    L'articolo 32 del GDPR richiede misure tecniche di sicurezza adeguate. Per qualsiasi sito web che memorizza dati personali dietro gli account degli utenti, non proteggere il flusso di reset è sempre più difficile da difendere in una verifica dell'autorità di vigilanza. Il reset flooding, l'enumerazione e il furto di token sono modelli di attacco ben documentati con contromisure ben note. La loro implementazione fa parte di una ragionevole postura ai sensi dell'articolo 32.

    Lista di controllo per l'implementazione

    Utilizzate questa lista di controllo per verificare il vostro attuale flusso di ripristino. Le voci sono ordinate in base all'impatto per sforzo di implementazione: le voci più importanti offrono la massima protezione con il minimo lavoro.

    • Risposte coerenti: Verificare che il modulo di reset restituisca lo stesso messaggio, lo stesso codice di stato e lo stesso tempo di risposta per gli account esistenti e per quelli non esistenti.
    • CAPTCHA nel modulo di reset: Aggiungere un CAPTCHA invisibile al modulo di richiesta di ripristino. Per WordPress: vedere la guida di WordPress. Per Keycloak: vedere la guida Keycloak.
    • Limitazione della velocità per account e per IP: Applicare limiti a entrambi i livelli. Rifiuta silenziosamente dopo la soglia: non rivela l'esistenza del limite.
    • Token crittograficamente forti: Verificare che il generatore di token utilizzi un CSPRNG con almeno 20 byte di entropia. Rifiutate gli ID sequenziali, i timestamp e gli schemi hash-of-email.
    • Scadenza del gettone: I gettoni scadono entro un'ora dall'emissione. I gettoni scadono immediatamente dopo l'utilizzo. Le nuove richieste di reset invalidano tutti i token precedenti per quell'account.
    • Intestazione Referrer-Policy: Set Politica dei referenti: no-referrer sulle pagine di conferma del reset. Esaminare tutte le risorse esterne caricate su queste pagine.
    • Nessuna domanda di sicurezza: Sostituite la verifica con quella basata su e-mail o TOTP. Verificate tutti i flussi di domande di sicurezza legacy ancora attivi nella vostra applicazione.
    • Azzeramento delle notifiche di richiesta: Inviate agli utenti un'e-mail quando viene attivato un reset, non solo quando viene completato.
    • Monitoraggio e allerta: Impostare avvisi per i picchi di volume azzerati per IP e per account. Correlazione con i modelli di errore di accesso.
    • HTTPS ovunque sui flussi di ripristino: Assicurarsi che tutte le pagine di ripristino e gli endpoint di invio dei token utilizzino HTTPS con TLS corrente. Rifiutare i token di ripristino inviati tramite HTTP.

    Domande frequenti

    Che cos'è l'abuso di reimpostazione della password?

    L'abuso della reimpostazione della password è l'uso improprio di un flusso di recupero dell'account per ottenere un accesso non autorizzato, enumerare gli account validi, inondare le caselle di posta o rubare i token di recupero. Si distingue dall'avvelenamento della password, che è una vulnerabilità tecnica specifica in cui un aggressore manipola il modo in cui viene generato il link di ripristino. L'abuso di reset è una categoria più ampia che comprende quattro modelli di attacco distinti: enumerazione, flooding, furto di token e progettazione di recupero debole.

    Qual è la differenza tra l'abuso e l'avvelenamento della password?

    L'avvelenamento della password è una tecnica specifica all'interno della più ampia categoria dell'abuso di reset. L'avvelenamento si verifica quando un aggressore manipola l'intestazione HTTP Host per reindirizzare un link di reset a un dominio controllato dall'aggressore. L'abuso di reset copre una serie più ampia di modelli: enumerazione degli account attraverso le differenze di risposta, inondazione di reset per sovraccaricare le caselle di posta, brute-forcing dei token e sfruttamento dei metodi di recupero deboli come le domande di sicurezza o l'intercettazione degli SMS.

    Il CAPTCHA impedisce l'abuso della reimpostazione della password?

    CAPTCHA blocca i modelli di abuso automatizzati: il reset flooding e l'enumerazione di account su larga scala. Non risolve la debolezza della generazione dei token, non previene la fuga di token attraverso le intestazioni dei referrer e non sostituisce la progettazione di risposte coerenti. Utilizzate il CAPTCHA come uno dei livelli di un più ampio sistema di sicurezza dei reset, non come unico controllo.

    Come fanno gli aggressori a enumerare gli account attraverso il modulo di reset?

    Se il modulo di reimpostazione restituisce risposte diverse per gli account esistenti e per quelli non esistenti (testo del messaggio diverso, codici di stato HTTP diversi o tempi di risposta sensibilmente diversi), un utente malintenzionato può inviare richieste di reimpostazione per un elenco di indirizzi e-mail e osservare quali restituiscono la risposta “account trovato”. In questo modo si può scoprire la base di utenti registrati senza dover decifrare alcuna password. La soluzione consiste nel restituire sempre la stessa risposta, indipendentemente dall'esistenza dell'account.

    Per quanto tempo deve essere valido un token di reset?

    Un'ora è un tempo massimo ragionevole per la maggior parte delle applicazioni. Per contesti di maggiore sicurezza (conti finanziari, sanità, accesso amministrativo), sono più appropriati 15-30 minuti. Il token deve scadere immediatamente dopo l'uso e tutti i token precedenti per un account devono essere invalidati quando viene richiesto un nuovo reset. I token che rimangono validi dopo l'uso sono una backdoor persistente.

    Il flusso di reimpostazione della password è un problema di GDPR?

    Sì, in due modi. In primo luogo, un attacco riuscito che porta all'accesso non autorizzato all'account è una violazione dei dati personali ai sensi del GDPR, che fa scattare la valutazione ai sensi dell'articolo 33 e i potenziali obblighi di notifica. In secondo luogo, i CAPTCHA basati sui cookie nelle pagine di recupero creano una domanda di consenso ePrivacy in un momento difficile per gli utenti. Un CAPTCHA senza cookie elimina completamente il requisito del consenso dal flusso di recupero.

    Lettura correlata

    Fonti primarie

    Scheda informativa OWASP sulla password dimenticata: risposte coerenti, design sicuro dei token e raccomandazioni per la limitazione del tasso di cambio.
    Scheda informativa sull'autenticazione OWASP: riautenticazione e pratiche di autenticazione sicura
    Accademia di sicurezza web PortSwigger: Avvelenamento della password: dettagli tecnici sullo sfruttamento dell'intestazione dell'host nei flussi di reset
    NIST SP 800-63B: guida sugli autenticatori segreti memorizzati e sui requisiti di entropia del segreto reimpostato
    Guida ai test OWASP: Funzionalità di reset delle password deboli
    CAPTCHA.eu: Cos'è l'avvelenamento da password?Definizione e distinzione tra avvelenamento e abuso di reset più ampio.
    CAPTCHA.eu: Come prevenire gli attacchi di acquisizione dell'account: contesto più ampio di sicurezza dell'autenticazione, compresi i flussi di ripristino.

    messaggi recenti

    it_ITItalian
    en_USEnglish de_DEGerman fr_FRFrench es_ESSpanish nl_NLDutch it_ITItalian