Un attacco informatico di tipo Username Enumeration permette ad un utente malevolo l’identificazione degli utenti registrati su una specifica web application, un servizio o un sistema. Tale attacco sfrutta una vulnerabilità di sicurezza o una scelta di progettazione dell’applicativo stesso e aumenta il rischio di accesso non autorizzato.
Generalmente viene definito Username Enumeration ma, in molti casi, l’indirizzo e-mail coincide con l’username aprendo altri possibili scenari di attacco quali Phishing, Credential Stuffing e altre tipologie di attacco mirato nei confronti di un utente.
La vulnerabilità può risultare più o meno difficile da identificare in base alle forme su cui si verifica e le sezioni in cui risiede. Di seguito vengono proposti alcune delle forme e sezioni più comuni in cui può essere presente.
Le forme più comuni in in cui si può manifestare la vulnerabilità sono le seguenti:
- Messaggi di errore distinti: in base alla risposta generata dall’applicativo è possibile identificare l’esistenza dell’utente. Alcuni esempi possono essere:
- messaggio: “l’utente non è presente nel sistema” (di conseguenza si può intuire che nel caso in cui il messaggio non sia presente l’utente esiste).
- contenuti differenti della pagina (non necessariamente visibili all’utente), codici di errore o redirect specifici.
- Tempi di risposta differenti: tali tempistiche possono variare notevolmente in base alla richiesta effettuata, ad esempio potrebbe avere tempi di risposta maggiori nel caso di utenti esistenti ed istantanei nel caso di utenti non validi.
- Risposte differenti per tipologia o stato dell’account: Nel caso in cui siano presenti account bloccati o sospesi è possibile che l’applicativo generi risposte differenti al fine di notificare tale stato, di conseguenza è possibile identificare l’esistenza dell’account che però risulta essere disabilitato.
Tale vulnerabilità inoltre può manifestarsi in varie sezioni relative all’autenticazione o del profilo utente:
- login: in questo caso solitamente è visibile grazie ad una notifica da parte della funzione login che fornisce informazioni relative all’esistenza o meno dell’utente.
- password reset: tale funzionalità solitamente permette di recuperare le credenziali dimenticate fornendo l’username o l’indirizzo e-mail. In questo caso, solitamente, viene notificato l’utente sull’effettivo successo della richiesta e tramite quest’ultima è possibile enumerare gli utenti presenti nel sistema.
- Bisogna tenere in considerazione che la funzionalità di reset, salvo errori di progettazione o disservizi, effettua l’invio di una e-mail all’utente che di conseguenza può allertare quest’ultimo in quanto non ha effettuato tale richiesta.
- registrazione: durante la registrazione è possibile che il nome utente o la mail siano già state utilizzate e nel caso in cui si inseriscano venga generato un errore che notifica l’utente che si sta registrando. Tale notifica può essere utilizzata per enumerare gli utenti già presenti nel sistema.
- pagine degli utenti: In base alla scelta di progettazione è possibile che le pagine utente siano visualizzare tramite id o username aprendo due possibili scenari.
- Nel caso dell’id se questo è numerico progressivo è possibile enumerare gli utenti presenti incrementando tale valore per accedere al profilo dell’utente successivo.
- Differente è il caso in cui venga utilizzato l’username in quanto è possibile identificare un utente in base alla riposta della pagina (ad esempio status code 200 o errore 404).
- api: solitamente utilizzate per richiedere o elaborare dati è possibile che siano affette da tale vulnerabilità in quanto è possibile che forniscano dati relativi agli utenti.
Tale vulnerabilità può avvenire anche al di fuori della sezione di accesso o del profilo utente come ad esempio nel caso di sezioni relative ad articoli, forum e tutto ciò che concerne con l’interazione tra utenti. Tali sezioni però non necessariamente rivelano informazioni relative a username ed e-mail.
La vulnerabilità può risultare più o meno difficile da identificare in base alle forme su cui si verifica e le sezioni in cui risiede. Di seguito vengono proposti alcune delle forme e sezioni più comuni in cui può essere presente.
Le forme più comuni in in cui si può manifestare la vulnerabilità sono le seguenti:
- Messaggi di errore distinti: in base alla risposta generata dall’applicativo è possibile identificare l’esistenza dell’utente. Alcuni esempi possono essere:
- messaggio: “l’utente non è presente nel sistema” (di conseguenza si può intuire che nel caso in cui il messaggio non sia presente l’utente esiste).
- contenuti differenti della pagina (non necessariamente visibili all’utente), codici di errore o redirect specifici.
- Tempi di risposta differenti: tali tempistiche possono variare notevolmente in base alla richiesta effettuata, ad esempio potrebbe avere tempi di risposta maggiori nel caso di utenti esistenti ed istantanei nel caso di utenti non validi.
- Risposte differenti per tipologia o stato dell’account: Nel caso in cui siano presenti account bloccati o sospesi è possibile che l’applicativo generi risposte differenti al fine di notificare tale stato, di conseguenza è possibile identificare l’esistenza dell’account che però risulta essere disabilitato.
Tale vulnerabilità inoltre può manifestarsi in varie sezioni relative all’autenticazione o del profilo utente:
- login: in questo caso solitamente è visibile grazie ad una notifica da parte della funzione login che fornisce informazioni relative all’esistenza o meno dell’utente.
- password reset: tale funzionalità solitamente permette di recuperare le credenziali dimenticate fornendo l’username o l’indirizzo e-mail. In questo caso, solitamente, viene notificato l’utente sull’effettivo successo della richiesta e tramite quest’ultima è possibile enumerare gli utenti presenti nel sistema.
- Bisogna tenere in considerazione che la funzionalità di reset, salvo errori di progettazione o disservizi, effettua l’invio di una e-mail all’utente che di conseguenza può allertare quest’ultimo in quanto non ha effettuato tale richiesta.
- registrazione: durante la registrazione è possibile che il nome utente o la mail siano già state utilizzate e nel caso in cui si inseriscano venga generato un errore che notifica l’utente che si sta registrando. Tale notifica può essere utilizzata per enumerare gli utenti già presenti nel sistema.
- pagine degli utenti: In base alla scelta di progettazione è possibile che le pagine utente siano visualizzare tramite id o username aprendo due possibili scenari.
- Nel caso dell’id se questo è numerico progressivo è possibile enumerare gli utenti presenti incrementando tale valore per accedere al profilo dell’utente successivo.
- Differente è il caso in cui venga utilizzato l’username in quanto è possibile identificare un utente in base alla riposta della pagina (ad esempio status code 200 o errore 404).
- api: solitamente utilizzate per richiedere o elaborare dati è possibile che siano affette da tale vulnerabilità in quanto è possibile che forniscano dati relativi agli utenti.
Tale vulnerabilità può avvenire anche al di fuori della sezione di accesso o del profilo utente come ad esempio nel caso di sezioni relative ad articoli, forum e tutto ciò che concerne con l’interazione tra utenti. Tali sezioni però non necessariamente rivelano informazioni relative a username ed e-mail.
Uno degli esempi più comuni di attacco avviene nella pagina di login, più precisamente se la funzionalità segnala quale parametro è errato permette di identificare gli utenti presenti nella piattaforma.
Esempio similare avviene nel caso della creazione di un nuovo utente:
In tal caso è anche possibile bypassare la creazione dell’account fornendo un email non valida (che genererà un errore) come dimostrato nella seguente immagine:
Infine, un ultimo esempio è identificabile nella sezione di reset della password:
Si ricorda però che tale funzione effettua un invio automatico di una e-mail all’utente nel caso in cui venga fornito un indirizzo valido.
Esistono diverse tipologie di mitigazione di tale vulnerabilità in base alla tipologia di identificazione rilevata:
- Adottare messaggi di errore generici: è preferibile utilizzare messaggi di errore generici che non rivelino informazioni dettagliate all’utente. Tale metodologia permette di mitigare la vulnerabilità relativa se identificata nella funzione di login.
- In questi caso è quindi preferibile un messaggio di errore del tipo “le credenziali inserite non sono corrette” piuttosto che specificare quale tra username e password è errata.
- Adottare messaggi di conferma generici, l’utilizzo di messaggi generici permette di evitare di condividere informazioni ad un utente malintenzionato in quanto non permette di capire il rispettivo successo dell’operazione.
- L’utilizzo del messaggio “se l’utente è corretto è stata inviata una email contenente i passaggi per cambiare la password” nella funzionalità di password reset non fornisce informazioni sull’effettivo successo dell’operazione se tale utente non ha accesso all’account e-mail stesso.
- Implementare tempi di risposta uniformi: in tal modo è possibile mitigare la vulnerabilità se questa è identificabile sulla base del tempo di risposta.
- Limitare le richieste effettuate da uno stesso utente effettuando un ban temporaneo o disabilitare la funzionalità in modo da limitare l’enumerazione.
- Se un determinato utente effettua vari tentativi di creazione di un account, di accesso o di reset della password in un breve arco temporale è preferibile inibire tale funzionalità per quell’utente (tramite un fingerprint dell’utente basandosi su dato come IP, Cookie, User-Agent, parametri del browser, etc).
- Implementare controlli aggiuntivi come l’uso di Captcha e token anti-CSRF in modo da limitare tool automatizzati inserendoli nelle sezioni citriche e verificandoli prima di eseguire la funzionalità.