Authentication

PortSwigger Academy – Authentication

Continua il percorso di apprendimento suggerito da “PortSwigger Academy”. Consiglio di iscriversi alla piattaforma, seguire le lezioni e soprattutto svolgere e completare i lab 🙂

Authentication

Authentication vulnerabilities

Almeno concettualmente, le vulnerabilità dell’autenticazione sono alcuni dei problemi più semplici da comprendere. Tuttavia, possono essere tra i più critici a causa dell’ovvia relazione tra autenticazione e sicurezza. Oltre a consentire potenzialmente agli aggressori l’accesso diretto a dati e funzionalità sensibili, espongono anche una superficie di attacco aggiuntiva per ulteriori exploit. Per questo motivo, imparare a identificare e sfruttare le vulnerabilità di autenticazione, incluso come aggirare le comuni misure di protezione, è un’abilità fondamentale.

In questa sezione, esamineremo alcuni dei meccanismi di autenticazione più comuni utilizzati dai siti Web e discuteremo le potenziali vulnerabilità in essi. Evidenzieremo sia le vulnerabilità intrinseche nei diversi meccanismi di autenticazione, sia alcune vulnerabilità tipiche introdotte dalla loro implementazione impropria. Infine, forniremo alcune indicazioni di base su come garantire che i propri meccanismi di autenticazione siano il più solidi possibile.

Cos’è l’autenticazione?

L’autenticazione è il processo di verifica dell’identità di un determinato utente o client. In altre parole, implica assicurarsi che siano davvero chi affermano di essere. Almeno in parte, i siti Web sono esposti a chiunque sia connesso a Internet per progettazione. Pertanto, robusti meccanismi di autenticazione sono un aspetto integrante di un’efficace sicurezza web.

Esistono tre fattori di autenticazione in cui è possibile classificare diversi tipi di autenticazione:

• Qualcosa che conosci, come una password o la risposta a una domanda di sicurezza. Questi sono a volte indicati come “fattori di conoscenza”.
• Qualcosa che hai, cioè un oggetto fisico come un telefono cellulare o un token di sicurezza. Questi sono talvolta indicati come “fattori di possesso”.
• Qualcosa che sei o fai, ad esempio, i tuoi dati biometrici o modelli di comportamento. Questi sono talvolta indicati come “fattori di inerenza”.

I meccanismi di autenticazione si basano su una gamma di tecnologie per verificare uno o più di questi fattori.

Qual è la differenza tra autenticazione e autorizzazione?

L’autenticazione è il processo di verifica che un utente sia veramente chi afferma di essere, mentre l’autorizzazione implica la verifica se un utente è autorizzato a fare qualcosa.

Nel contesto di un sito Web o di un’applicazione Web, l’autenticazione determina se qualcuno che tenta di accedere al sito con il nome utente Carlos123 è realmente la stessa persona che ha creato l’account.

Una volta che Carlos123 è stato autenticato, le sue autorizzazioni determinano se è autorizzato o meno, ad esempio, ad accedere alle informazioni personali su altri utenti o eseguire azioni come l’eliminazione dell’account di un altro utente.

Come nascono le vulnerabilità di autenticazione?

In generale, la maggior parte delle vulnerabilità nei meccanismi di autenticazione si presenta in due modi:

• I meccanismi di autenticazione sono deboli perché non riescono a proteggere adeguatamente dagli attacchi di forza bruta.
• I difetti logici o la scarsa codifica nell’implementazione consentono a un utente malintenzionato di aggirare completamente i meccanismi di autenticazione. Questo è talvolta indicato come “autenticazione interrotta”.

In molte aree dello sviluppo web, i difetti logici (logic flaws) causeranno semplicemente un comportamento imprevisto del sito Web, il che potrebbe rappresentare o meno un problema di sicurezza. Tuttavia, poiché l’autenticazione è fondamentale per la sicurezza, la probabilità che una logica di autenticazione errata esponga il sito Web a problemi di sicurezza è chiaramente elevata.

Qual è l’impatto dell’autenticazione vulnerabile?

L’impatto delle vulnerabilità di autenticazione può essere molto grave. Una volta che un utente malintenzionato ha aggirato l’autenticazione o si è introdotto con la forza bruta nell’account di un altro utente, ha accesso a tutti i dati e le funzionalità dell’account compromesso. Se sono in grado di compromettere un account con privilegi elevati, come un amministratore di sistema, potrebbero assumere il pieno controllo dell’intera applicazione e potenzialmente ottenere l’accesso all’infrastruttura interna.

Anche la compromissione di un account con privilegi limitati potrebbe comunque concedere a un utente malintenzionato l’accesso a dati che altrimenti non dovrebbe avere, come informazioni aziendali sensibili dal punto di vista commerciale. Anche se l’account non ha accesso a dati sensibili, potrebbe comunque consentire all’attaccante di accedere a pagine aggiuntive, che forniscono un’ulteriore superficie di attacco. Spesso, alcuni attacchi ad alta gravità non saranno possibili da pagine accessibili pubblicamente, ma potrebbero essere possibili da una pagina interna.

Vulnerabilità nei meccanismi di autenticazione

Il sistema di autenticazione di un sito Web è generalmente costituito da diversi meccanismi distinti in cui possono verificarsi vulnerabilità. Alcune vulnerabilità sono ampiamente applicabili in tutti questi contesti, mentre altre sono più specifiche per la funzionalità fornita.

Esamineremo più da vicino alcune delle vulnerabilità più comuni nelle seguenti aree:

• Vulnerabilities in password-based login
• Vulnerabilities in multi-factor authentication
• Vulnerabilities in other authentication mechanisms

Si noti che molti dei laboratori richiedono di enumerare nomi utente e password di forza bruta. Per venirci in aiuto, “PortSwigger Academy” fornisce un elenco di usernames e passwords da utilizzare per risolvere i lab.

Vulnerabilità nei meccanismi di autenticazione di terze parti

Se si è interessati ai meccanismi di autenticazione,“PortSwigger Academy” consiglia, dopo aver completato i principali laboratori di autenticazione, di provare ad affrontare i loro laboratori di autenticazione OAuth.

Per saperne di più

OAuth authentication

Prevenzione degli attacchi ai propri meccanismi di autenticazione

Abbiamo dimostrato diversi modi in cui i siti Web possono essere vulnerabili a causa del modo in cui implementano l’autenticazione. Per ridurre il rischio di tali attacchi sui propri siti web, ci sono diversi principi generali che dovresti sempre cercare di seguire.

Per saperne di più

How to secure your authentication mechanisms

(torna su)

Vulnerabilità nell’accesso basato su password

In questa sezione esamineremo più da vicino alcune delle vulnerabilità più comuni che si verificano nei meccanismi di accesso basati su password. Suggeriremo anche modi in cui questi possono essere potenzialmente sfruttati. Ci sono anche alcuni laboratori interattivi in ​​modo da esercitarsi sullo sfruttamento di tali vulnerabilità.

Per i siti Web che adottano un processo di accesso basato su password, gli utenti si registrano per un account da soli o ricevono un account da un amministratore. Questo account è associato a un nome utente univoco e una password segreta, che l’utente inserisce in un modulo di accesso per autenticarsi.

In questo scenario, il semplice fatto di conoscere la password segreta è considerato una prova sufficiente dell’identità dell’utente. Di conseguenza, la sicurezza del sito web verrebbe compromessa se un utente malintenzionato fosse in grado di ottenere o indovinare le credenziali di accesso di un altro utente.

Ciò può essere ottenuto in vari modi, come esploreremo di seguito.

Attacchi di forza bruta

Un attacco di forza bruta si verifica quando un utente malintenzionato utilizza un sistema di tentativi ed errori nel tentativo di indovinare credenziali utente valide. Questi attacchi sono in genere automatizzati utilizzando elenchi di parole di nomi utente e password. L’automazione di questo processo, in particolare utilizzando strumenti dedicati, consente potenzialmente a un utente malintenzionato di effettuare un numero elevato di tentativi di accesso ad alta velocità.

La forzatura bruta non è sempre solo un caso di ipotesi completamente casuali su nomi utente e password. Utilizzando anche la logica di base o le conoscenze pubblicamente disponibili, gli aggressori possono perfezionare gli attacchi di forza bruta per fare ipotesi molto più plausibili. Ciò aumenta notevolmente l’efficienza di tali attacchi. I siti Web che si basano sull’accesso basato su password come unico metodo di autenticazione degli utenti possono essere altamente vulnerabili se non implementano una protezione di forza bruta sufficiente.

Brute-forcing usernames

I nomi utente sono particolarmente facili da indovinare se sono conformi a uno schema riconoscibile, come un indirizzo e-mail. Ad esempio, è molto comune vedere gli accessi aziendali nel formato nome.cognome@società.com. Tuttavia, anche se non esiste uno schema ovvio, a volte vengono creati anche account con privilegi elevati utilizzando nomi utente prevedibili, come admin o administrator.

Durante l’audit, controlla se il sito web rivela pubblicamente potenziali nomi utente. Ad esempio, sei in grado di accedere ai profili utente senza effettuare il login? Anche se il contenuto effettivo dei profili è nascosto, il nome utilizzato nel profilo a volte è uguale al nome utente di accesso. Dovresti anche controllare le risposte HTTP per vedere se sono stati divulgati indirizzi email. Occasionalmente, le risposte contengono indirizzi e-mail di utenti con privilegi elevati come amministratori e supporto IT.

Brute-forcing passwords

Allo stesso modo, le password possono subire attacchi a forza bruta, con difficoltà che variano in base alla forza della password. Molti siti Web adottano una qualche forma di politica delle password, che costringe gli utenti a creare password ad alta entropia che, almeno in teoria, sono più difficili da decifrare utilizzando la sola forza bruta. Ciò comporta in genere l’applicazione delle password con:

• Un numero minimo di caratteri
• Un misto di lettere minuscole e maiuscole
• Almeno un carattere speciale

Tuttavia, mentre le password ad alta entropia sono difficili da decifrare solo per i computer, possiamo utilizzare una conoscenza di base del comportamento umano per sfruttare le vulnerabilità che gli utenti introducono inconsapevolmente a questo sistema. Invece di creare una password complessa con una combinazione casuale di caratteri, gli utenti spesso prendono una password che possono ricordare e cercano di forzarla affinché si adatti alla politica della password. Ad esempio, se mypassword non è consentito, gli utenti possono provare qualcosa come Mypassword1! o invece Myp4$$w0rd.

Nei casi in cui la politica richiede agli utenti di modificare regolarmente le proprie password, è anche normale che gli utenti apportino solo modifiche minori e prevedibili alla propria password preferita. Ad esempio, Miapassword1! diventa Miapassword1? o Miapassword2!.

Questa conoscenza delle credenziali probabili e dei modelli prevedibili significa che gli attacchi di forza bruta possono spesso essere molto più sofisticati, e quindi efficaci, rispetto alla semplice ripetizione di ogni possibile combinazione di caratteri.

Username enumeration

L’enumerazione del nome utente è quando un utente malintenzionato è in grado di osservare i cambiamenti nel comportamento del sito Web per identificare se un determinato nome utente è valido.

L’enumerazione del nome utente in genere si verifica nella pagina di accesso, ad esempio, quando si immette un nome utente valido ma una password errata, oppure nei moduli di registrazione quando si immette un nome utente già utilizzato. Ciò riduce notevolmente il tempo e lo sforzo necessari per forzare un accesso in quanto l’attaccante è in grado di generare rapidamente un elenco ristretto di nomi utente validi.

Durante il tentativo di applicare la forza bruta a una pagina di accesso, dovresti prestare particolare attenzione a eventuali differenze in:

• Codici di stato: durante un attacco di forza bruta, è probabile che il codice di stato HTTP restituito sia lo stesso per la stragrande maggioranza delle ipotesi perché la maggior parte di esse sarà sbagliata. Se un’ipotesi restituisce un codice di stato diverso, questa è una forte indicazione che il nome utente era corretto. È consigliabile che i siti web restituiscano sempre lo stesso codice di stato indipendentemente dal risultato, ma questa pratica non viene sempre seguita.
• Messaggi di errore: a volte il messaggio di errore restituito è diverso a seconda che sia il nome utente che la password siano errati o solo la password sia errata. È buona prassi che i siti Web utilizzino messaggi generici identici in entrambi i casi, ma a volte si insinuano piccoli errori di battitura. Un solo carattere fuori posto distingue i due messaggi, anche nei casi in cui il carattere non è visibile sulla pagina visualizzata.
• Tempi di risposta: se la maggior parte delle richieste è stata gestita con un tempo di risposta simile, tutte quelle che si discostano da questo suggeriscono che dietro le quinte stava accadendo qualcosa di diverso. Questa è un’altra indicazione che il nome utente indovinato potrebbe essere corretto. Ad esempio, un sito Web potrebbe verificare solo se la password è corretta se il nome utente è valido. Questo passaggio aggiuntivo potrebbe causare un leggero aumento del tempo di risposta. Questo può essere sottile, ma un utente malintenzionato può rendere questo ritardo più evidente inserendo una password eccessivamente lunga che il sito web richiede molto più tempo per essere gestita.

Lab: Username enumeration via different responses

Lab: Username enumeration via subtly different responses

Lab: Username enumeration via response timing

Protezione dalla forza bruta imperfetta

È molto probabile che un attacco di forza bruta comporti molte ipotesi fallite prima che l’aggressore comprometta con successo un account. Logicamente, la protezione dalla forza bruta ruota attorno al tentativo di rendere il più complicato possibile l’automazione del processo e rallentare la velocità con cui un utente malintenzionato può tentare l’accesso. I due modi più comuni per prevenire gli attacchi di forza bruta sono:

• bloccare l’account a cui l’utente remoto sta tentando di accedere se effettua troppi tentativi di accesso non riusciti;
• bloccare l’indirizzo IP dell’utente remoto se effettua troppi tentativi di accesso in rapida successione.

Entrambi gli approcci offrono diversi gradi di protezione, ma nessuno dei due è invulnerabile, soprattutto se implementato utilizzando una logica errata.

Ad esempio, a volte potresti scoprire che il tuo IP viene bloccato se non riesci ad accedere troppe volte. In alcune implementazioni, il contatore del numero di tentativi falliti si reimposta se il proprietario IP accede correttamente. Ciò significa che un utente malintenzionato dovrebbe semplicemente accedere al proprio account ogni pochi tentativi per impedire che questo limite venga raggiunto.

In questo caso, è sufficiente includere semplicemente le proprie credenziali di accesso a intervalli regolari nell’elenco delle parole per rendere questa difesa praticamente inutile.

Lab: Broken brute-force protection, IP block

Blocco dell’account

Un modo in cui i siti Web tentano di prevenire la forzatura bruta è bloccare l’account se vengono soddisfatti determinati criteri sospetti, in genere un determinato numero di tentativi di accesso non riusciti. Proprio come con i normali errori di accesso, anche le risposte del server che indicano che un account è bloccato possono aiutare un utente malintenzionato a enumerare i nomi utente.

Lab: Username enumeration via account lock

Il blocco di un account offre una certa protezione contro la forzatura bruta mirata a un account specifico. Tuttavia, questo approccio non riesce a prevenire adeguatamente gli attacchi di forza bruta in cui l’aggressore tenta semplicemente di accedere a qualsiasi account casuale possibile.

Ad esempio, è possibile utilizzare il seguente metodo per aggirare questo tipo di protezione:

1. Stabilire un elenco di nomi utente candidati che potrebbero essere validi. Ciò potrebbe avvenire tramite l’enumerazione dei nomi utente o semplicemente in base a un elenco di nomi utente comuni.
2. Decidi un elenco molto ristretto di password che ritieni possa avere almeno un utente. Fondamentalmente, il numero di password selezionate non deve superare il numero di tentativi di accesso consentiti. Ad esempio, se hai calcolato che il limite è di 3 tentativi, devi scegliere un massimo di 3 tentativi di password.
3. Utilizzando uno strumento come Burp Intruder, prova ciascuna delle password selezionate con ciascuno dei nomi utente candidati. In questo modo, puoi tentare di forzare ogni account senza attivare il blocco dell’account. È necessario che un singolo utente utilizzi una delle tre password per compromettere un account.

Inoltre, il blocco degli account non protegge dagli attacchi di credential stuffing. Ciò comporta l’utilizzo di un enorme dizionario di coppie nome utente: password, composto da credenziali di accesso autentiche rubate durante le violazioni dei dati. Il credential stuffing si basa sul fatto che molte persone riutilizzano lo stesso nome utente e la stessa password su più siti Web e, pertanto, esiste la possibilità che alcune delle credenziali compromesse nel dizionario siano valide anche sul sito Web di destinazione. Il blocco dell’account non protegge dal credential stuffing perché ciascun nome utente viene tentato una sola volta. Il credential stuffing è particolarmente pericoloso perché a volte può portare l’aggressore a compromettere molti account diversi con un solo attacco automatizzato.

User rate limiting

Un altro modo in cui i siti Web cercano di prevenire gli attacchi di forza bruta è attraverso la limitazione della frequenza degli utenti. In questo caso, effettuare troppe richieste di accesso in un breve periodo di tempo causa il blocco del tuo indirizzo IP. In genere, l’IP può essere sbloccato solo in uno dei seguenti modi:

• automaticamente dopo che è trascorso un certo periodo di tempo;
• manualmente da un amministratore;
• manualmente dall’utente dopo aver completato con successo un CAPTCHA.

La limitazione della frequenza degli utenti è talvolta preferita al blocco dell’account poiché è meno incline all’enumerazione dei nomi utente e agli attacchi di negazione del servizio. Tuttavia, non è ancora completamente sicuro. Come abbiamo visto in un esempio in un laboratorio precedente, esistono diversi modi in cui un utente malintenzionato può manipolare il proprio IP apparente per aggirare il blocco.

Poiché il limite si basa sulla frequenza delle richieste HTTP inviate dall’indirizzo IP dell’utente, a volte è anche possibile aggirare questa difesa se si riesce a indovinare più password con una singola richiesta.

Lab: Broken brute-force protection, multiple credentials per request

Autenticazione di base HTTP

Sebbene sia piuttosto vecchio, la sua relativa semplicità e facilità di implementazione significa che a volte potresti vedere utilizzata l’autenticazione di base HTTP. Nell’autenticazione di base HTTP, il client riceve un token di autenticazione dal server, che viene costruito concatenando nome utente e password e codificandolo in Base64. Questo token viene memorizzato e gestito dal browser, che lo aggiunge automaticamente all’intestazione Authorization di ogni richiesta successiva come segue:

Authorization: Basic base64(username:password)

Per una serie di motivi, questo non è generalmente considerato un metodo di autenticazione sicuro. Innanzitutto, comporta l’invio ripetuto delle credenziali di accesso dell’utente ad ogni richiesta. A meno che il sito Web non implementi anche l’HSTS, le credenziali dell’utente possono essere catturate in un attacco man-in-the-middle.

Inoltre, le implementazioni dell’autenticazione di base HTTP spesso non supportano la protezione dalla forza bruta. Poiché il token è costituito esclusivamente da valori statici, ciò può renderlo vulnerabile alla forza bruta.

L’autenticazione di base HTTP è inoltre particolarmente vulnerabile agli exploit legati alla sessione, in particolare CSRF, contro i quali non offre di per sé alcuna protezione.

In alcuni casi, lo sfruttamento dell’autenticazione di base HTTP vulnerabile potrebbe garantire a un utente malintenzionato solo l’accesso a una pagina apparentemente poco interessante. Tuttavia, oltre a fornire un’ulteriore superficie di attacco, le credenziali esposte in questo modo potrebbero essere riutilizzate in altri contesti più riservati.

(torna su)

Vulnerabilità nell’autenticazione a più fattori

In questa sezione esamineremo alcune delle vulnerabilità che possono verificarsi nei meccanismi di autenticazione a più fattori. Ci sono anche diversi laboratori interattivi per dimostrare come sfruttare queste vulnerabilità nell’autenticazione a più fattori.

Molti siti Web si affidano esclusivamente all’autenticazione a fattore singolo utilizzando una password per autenticare gli utenti. Tuttavia, alcuni richiedono agli utenti di dimostrare la propria identità utilizzando più fattori di autenticazione.

La verifica dei fattori biometrici non è pratica per la maggior parte dei siti web. Tuttavia, è sempre più comune vedere l’autenticazione a due fattori (2FA) sia obbligatoria che facoltativa basata su qualcosa che conosci e qualcosa che possiedi. Ciò di solito richiede agli utenti di inserire sia una password tradizionale che un codice di verifica temporaneo da un dispositivo fisico fuori banda in loro possesso.

Token di autenticazione a due fattori

I codici di verifica vengono solitamente letti dall’utente da un dispositivo fisico di qualche tipo. Molti siti Web ad alta sicurezza ora forniscono agli utenti un dispositivo dedicato a questo scopo, come il token RSA o il dispositivo con tastiera utilizzato per accedere al servizio bancario online o al laptop di lavoro. Oltre ad essere realizzati appositamente per la sicurezza, questi dispositivi dedicati hanno anche il vantaggio di generare direttamente il codice di verifica. È anche comune che i siti Web utilizzino un’app mobile dedicata, come Google Authenticator, per lo stesso motivo.

Alcuni siti web, invece, inviano i codici di verifica al cellulare dell’utente sotto forma di messaggio di testo. Anche se tecnicamente questo sta ancora verificando il fattore “qualcosa che hai”, è aperto ad abusi. Innanzitutto, il codice viene trasmesso tramite SMS anziché essere generato dal dispositivo stesso. Ciò crea la possibilità che il codice venga intercettato. Esiste anche il rischio di SIM Swapping, per cui l’aggressore si procura in modo fraudolento una carta SIM con il numero di telefono della vittima. L’aggressore riceverebbe quindi tutti i messaggi SMS inviati alla vittima, compreso quello contenente il codice di verifica.

Bypassare l’autenticazione a due fattori

A volte, l’implementazione dell’autenticazione a due fattori è viziata al punto che può essere completamente aggirata.

Se all’utente viene prima richiesto di inserire una password e poi un codice di verifica in una pagina separata, l’utente si trova effettivamente in uno stato di “accesso” prima di aver inserito il codice di verifica. In questo caso, vale la pena verificare se è possibile passare direttamente alle pagine “solo loggato” dopo aver completato il primo passaggio di autenticazione. Occasionalmente, scoprirai che un sito Web in realtà non controlla se hai completato o meno il secondo passaggio prima di caricare la pagina.

Lab: 2FA simple bypass

Logica di verifica a due fattori difettosa

La logica difettosa nell’autenticazione a due fattori significa che dopo che un utente ha completato il passaggio iniziale di accesso, il sito Web non verifica adeguatamente che lo stesso utente stia completando il secondo passaggio.

Ad esempio, l’utente accede con le normali credenziali nel primo passaggio come segue:

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

Gli viene quindi assegnato un cookie relativo all’account, prima di essere portato alla seconda fase del processo di accesso:

HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

Quando si invia il codice di verifica, la richiesta utilizza questo cookie per determinare a quale account l’utente sta tentando di accedere:

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

n questo caso, un utente malintenzionato potrebbe accedere utilizzando le proprie credenziali, ma poi modificare il valore del cookie dell’account con qualsiasi nome utente arbitrario quando invia il codice di verifica.

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

Ciò è estremamente pericoloso se l’aggressore è in grado di forzare il codice di verifica in quanto gli consentirebbe di accedere ad account di utenti arbitrari basati interamente sul loro nome utente. Non avrebbero nemmeno bisogno di conoscere la password dell’utente.

Lab: 2FA broken logic

Brute-forcing codici di verifica 2FA

Come per le password, i siti web devono adottare misure per impedire la forzatura bruta del codice di verifica 2FA. Ciò è particolarmente importante perché il codice è spesso un semplice numero di 4 o 6 cifre. Senza un’adeguata protezione dalla forza bruta, decifrare un codice del genere è banale.
Alcuni siti Web tentano di impedire ciò disconnettendo automaticamente un utente se inserisce un certo numero di codici di verifica errati. Ciò è inefficace nella pratica perché un utente malintenzionato avanzato può persino automatizzare questo processo in più fasi creando macro per Burp Intruder. A questo scopo è possibile utilizzare anche l’estensione Turbo Intruder.

Lab: 2FA bypass using a brute-force attack

(torna su)

Vulnerabilità in altri meccanismi di autenticazione

In questa sezione esamineremo alcune delle funzionalità supplementari correlate all’autenticazione e dimostreremo come queste possano essere vulnerabili. Vi sono anche diversi laboratori interattivi che possono essere utilizzati per mettere in pratica l’argomento.

Oltre alla funzionalità di accesso di base, la maggior parte dei siti Web fornisce funzionalità supplementari per consentire agli utenti di gestire il proprio account. Ad esempio, gli utenti in genere possono modificare la propria password o reimpostarla quando la dimenticano. Questi meccanismi possono anche introdurre vulnerabilità che possono essere sfruttate da un utente malintenzionato.

I siti web di solito fanno attenzione a evitare vulnerabilità ben note nelle loro pagine di accesso. Ma è facile trascurare il fatto che è necessario adottare misure simili per garantire che le funzionalità correlate siano altrettanto robuste. Ciò è particolarmente importante nei casi in cui un utente malintenzionato è in grado di creare il proprio account e, di conseguenza, ha un facile accesso per studiare queste pagine aggiuntive.

Mantenere gli utenti connessi

Una caratteristica comune è la possibilità di rimanere connesso anche dopo aver chiuso una sessione del browser. Di solito si tratta di una semplice casella etichettata come “Ricordami” o “Resta connesso”.

Questa funzionalità viene spesso implementata generando un token “ricordami” di qualche tipo, che viene quindi archiviato in un cookie persistente. Poiché il possesso di questo cookie consente effettivamente di bypassare l’intero processo di accesso, è buona norma che questo cookie sia poco pratico da indovinare. Tuttavia, alcuni siti Web generano questo cookie in base a una concatenazione prevedibile di valori statici, come il nome utente e un timestamp. Alcuni addirittura utilizzano la password come parte del cookie. Questo approccio è particolarmente pericoloso se un utente malintenzionato è in grado di creare il proprio account perché può studiare il proprio cookie e potenzialmente dedurre come viene generato. Una volta elaborata la formula, possono provare a forzare i cookie di altri utenti per ottenere l’accesso ai loro account.

Alcuni siti Web presumono che se il cookie è crittografato in qualche modo non sarà individuabile anche se utilizza valori statici. Sebbene ciò possa essere vero se eseguito correttamente, la “crittografia” ingenua del cookie utilizzando una semplice codifica bidirezionale come Base64 non offre alcuna protezione di sorta. Anche l’utilizzo di una crittografia adeguata con una funzione hash unidirezionale non è completamente a prova di bomba. Se l’aggressore è in grado di identificare facilmente l’algoritmo di hashing e non viene utilizzato alcun salt, può potenzialmente forzare il cookie semplicemente eseguendo l’hashing dei propri elenchi di parole. Questo metodo può essere utilizzato per aggirare i limiti dei tentativi di accesso se un limite simile non viene applicato alle ipotesi sui cookie.

Lab: Brute-forcing a stay-logged-in cookie

Anche se l’aggressore non è in grado di creare il proprio account, potrebbe comunque riuscire a sfruttare questa vulnerabilità. Utilizzando le tecniche consuete, come XSS, un utente malintenzionato potrebbe rubare il cookie “ricordami” di un altro utente e dedurre da quello come è costruito il cookie. Se il sito web è stato creato utilizzando un framework open source, i dettagli chiave della costruzione dei cookie potrebbero anche essere documentati pubblicamente.

In alcuni rari casi, potrebbe essere possibile ottenere la password effettiva di un utente in chiaro da un cookie, anche se è sottoposta ad hashing. Online sono disponibili versioni con hash di elenchi di password noti, quindi se la password dell’utente appare in uno di questi elenchi, decodificare l’hash a volte può essere banale come semplicemente incollarlo in un motore di ricerca. Ciò dimostra l’importanza del salt in una crittografia efficace.

Lab: Offline password cracking

Reimpostazione delle password degli utenti

In pratica, è un dato di fatto che alcuni utenti dimenticheranno la propria password, quindi è normale avere un modo per reimpostarla. Poiché in questo scenario la consueta autenticazione basata su password è ovviamente impossibile, i siti Web devono fare affidamento su metodi alternativi per assicurarsi che l’utente reale reimposti la propria password. Per questo motivo, la funzionalità di reimpostazione della password è intrinsecamente pericolosa e deve essere implementata in modo sicuro.

Esistono diversi modi in cui questa funzionalità viene comunemente implementata, con diversi gradi di vulnerabilità.

Invio password tramite e-mail

Dovrebbe essere ovvio che inviare agli utenti la loro password attuale non dovrebbe mai essere possibile se un sito web gestisce le password in modo sicuro. Alcuni siti Web generano invece una nuova password e la inviano all’utente tramite e-mail.

In generale è da evitare l’invio di password persistenti su canali non sicuri. In questo caso, la sicurezza si basa sulla scadenza della password generata dopo un periodo molto breve o sulla modifica immediata della password da parte dell’utente. Altrimenti, questo approccio è altamente suscettibile agli attacchi man-in-the-middle.

Anche la posta elettronica non è generalmente considerata sicura dato che le caselle di posta sono persistenti e non realmente progettate per l’archiviazione sicura di informazioni riservate. Molti utenti inoltre sincronizzano automaticamente la propria casella di posta tra più dispositivi attraverso canali non sicuri.

Reimpostazione delle password utilizzando un URL

Un metodo più efficace per reimpostare le password consiste nell’inviare agli utenti un URL univoco che li indirizzi a una pagina di reimpostazione della password. Le implementazioni meno sicure di questo metodo utilizzano un URL con un parametro facilmente indovinabile per identificare quale account viene reimpostato, ad esempio: 

http://vulnerable-website.com/reset-password?user=victim-user

In questo esempio, un utente malintenzionato potrebbe modificare il parametro utente per fare riferimento a qualsiasi nome utente identificato. Verrebbero quindi indirizzati direttamente a una pagina in cui possono potenzialmente impostare una nuova password per questo utente arbitrario.

Un’implementazione migliore di questo processo consiste nel generare un token ad alta entropia difficile da indovinare e creare l’URL di reimpostazione basato su quello. Nella migliore delle ipotesi, questo URL non dovrebbe fornire suggerimenti su quale password dell’utente viene reimpostata.

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

Quando l’utente visita questo URL, il sistema dovrebbe verificare se questo token esiste sul back-end e, in tal caso, quale password dell’utente deve reimpostare. Questo token dovrebbe scadere dopo un breve periodo di tempo ed essere distrutto immediatamente dopo la reimpostazione della password.

Tuttavia, alcuni siti Web non riescono a convalidare nuovamente il token quando viene inviato il modulo di reimpostazione. In questo caso, un utente malintenzionato potrebbe semplicemente visitare il modulo di reimpostazione dal proprio account, eliminare il token e sfruttare questa pagina per reimpostare la password di un utente arbitrario.

Lab: Password reset broken logic

Se l’URL nell’e-mail di reimpostazione viene generato dinamicamente, anche questo potrebbe essere vulnerabile all’avvelenamento da reimpostazione della password. In questo caso, un utente malintenzionato può potenzialmente rubare il token di un altro utente e utilizzarlo per modificare la propria password.

Lab: Password reset poisoning via middleware

Per saperne di più

Password reset poisoning

Modifica delle password degli utenti

In genere, la modifica della password comporta l’immissione della password corrente e quindi della nuova password due volte. Queste pagine si basano fondamentalmente sullo stesso processo di verifica della corrispondenza dei nomi utente e delle password attuali come fa una normale pagina di accesso. Pertanto, queste pagine possono essere vulnerabili alle stesse tecniche.

La funzionalità di modifica della password può essere particolarmente pericolosa se consente a un utente malintenzionato di accedervi direttamente senza aver effettuato l’accesso come utente vittima. Ad esempio, se il nome utente viene fornito in un campo nascosto, un utente malintenzionato potrebbe essere in grado di modificare questo valore nella richiesta per prendere di mira utenti arbitrari. Questo può essere potenzialmente sfruttato per enumerare nomi utente e password a forza bruta.

Lab: Password brute-force via password change

(torna su)