Authentication<\/strong><\/p>\n\n\n\n Authentication vulnerabilities<\/strong><\/p>\n\n\n\n Almeno concettualmente, le vulnerabilit\u00e0 dell\u2019autenticazione sono alcuni dei problemi pi\u00f9 semplici da comprendere. Tuttavia, possono essere tra i pi\u00f9 critici a causa dell\u2019ovvia relazione tra autenticazione e sicurezza. Oltre a consentire potenzialmente agli aggressori l\u2019accesso diretto a dati e funzionalit\u00e0 sensibili, espongono anche una superficie di attacco aggiuntiva per ulteriori exploit. Per questo motivo, imparare a identificare e sfruttare le vulnerabilit\u00e0 di autenticazione, incluso come aggirare le comuni misure di protezione, \u00e8 un\u2019abilit\u00e0 fondamentale.<\/p>\n\n\n\n In questa sezione, esamineremo alcuni dei meccanismi di autenticazione pi\u00f9 comuni utilizzati dai siti Web e discuteremo le potenziali vulnerabilit\u00e0 in essi. Evidenzieremo sia le vulnerabilit\u00e0 intrinseche nei diversi meccanismi di autenticazione, sia alcune vulnerabilit\u00e0 tipiche introdotte dalla loro implementazione impropria. Infine, forniremo alcune indicazioni di base su come garantire che i propri meccanismi di autenticazione siano il pi\u00f9 solidi possibile.<\/p>\n\n\n\n Cos\u2019\u00e8 l\u2019autenticazione?<\/strong><\/p>\n\n\n\n L\u2019autenticazione \u00e8 il processo di verifica dell\u2019identit\u00e0 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\u2019efficace sicurezza web.<\/p>\n\n\n\n Esistono tre fattori di autenticazione in cui \u00e8 possibile classificare diversi tipi di autenticazione:<\/p>\n\n\n\n I meccanismi di autenticazione si basano su una gamma di tecnologie per verificare uno o pi\u00f9 di questi fattori.<\/p>\n\n\n\n Qual \u00e8 la differenza tra autenticazione e autorizzazione?<\/strong><\/p>\n\n\n\n L\u2019autenticazione \u00e8 il processo di verifica che un utente sia veramente chi afferma di essere, mentre l\u2019autorizzazione implica la verifica se un utente \u00e8 autorizzato a fare qualcosa.<\/p>\n\n\n\n Nel contesto di un sito Web o di un\u2019applicazione Web, l\u2019autenticazione determina se qualcuno che tenta di accedere al sito con il nome utente Carlos123<\/em> \u00e8 realmente la stessa persona che ha creato l\u2019account.<\/p>\n\n\n\n Una volta che Carlos123<\/em> \u00e8 stato autenticato, le sue autorizzazioni determinano se \u00e8 autorizzato o meno, ad esempio, ad accedere alle informazioni personali su altri utenti o eseguire azioni come l\u2019eliminazione dell\u2019account di un altro utente.<\/p>\n\n\n\n Come nascono le vulnerabilit\u00e0 di autenticazione?<\/strong><\/p>\n\n\n\n In generale, la maggior parte delle vulnerabilit\u00e0 nei meccanismi di autenticazione si presenta in due modi:<\/p>\n\n\n\n In molte aree dello sviluppo web, i difetti logici (logic flaws<\/a>) causeranno semplicemente un comportamento imprevisto del sito Web, il che potrebbe rappresentare o meno un problema di sicurezza. Tuttavia, poich\u00e9 l\u2019autenticazione \u00e8 fondamentale per la sicurezza, la probabilit\u00e0 che una logica di autenticazione errata esponga il sito Web a problemi di sicurezza \u00e8 chiaramente elevata.<\/p>\n\n\n\n Qual \u00e8 l\u2019impatto dell\u2019autenticazione vulnerabile?<\/strong><\/p>\n\n\n\n L\u2019impatto delle vulnerabilit\u00e0 di autenticazione pu\u00f2 essere molto grave. Una volta che un utente malintenzionato ha aggirato l\u2019autenticazione o si \u00e8 introdotto con la forza bruta nell\u2019account di un altro utente, ha accesso a tutti i dati e le funzionalit\u00e0 dell\u2019account compromesso. Se sono in grado di compromettere un account con privilegi elevati, come un amministratore di sistema, potrebbero assumere il pieno controllo dell\u2019intera applicazione e potenzialmente ottenere l\u2019accesso all\u2019infrastruttura interna.<\/p>\n\n\n\n Anche la compromissione di un account con privilegi limitati potrebbe comunque concedere a un utente malintenzionato l\u2019accesso a dati che altrimenti non dovrebbe avere, come informazioni aziendali sensibili dal punto di vista commerciale. Anche se l\u2019account non ha accesso a dati sensibili, potrebbe comunque consentire all\u2019attaccante di accedere a pagine aggiuntive, che forniscono un\u2019ulteriore superficie di attacco. Spesso, alcuni attacchi ad alta gravit\u00e0 non saranno possibili da pagine accessibili pubblicamente, ma potrebbero essere possibili da una pagina interna.<\/p>\n\n\n\n Vulnerabilit\u00e0 nei meccanismi di autenticazione<\/strong><\/p>\n\n\n\n Il sistema di autenticazione di un sito Web \u00e8 generalmente costituito da diversi meccanismi distinti in cui possono verificarsi vulnerabilit\u00e0. Alcune vulnerabilit\u00e0 sono ampiamente applicabili in tutti questi contesti, mentre altre sono pi\u00f9 specifiche per la funzionalit\u00e0 fornita.<\/p>\n\n\n\n Esamineremo pi\u00f9 da vicino alcune delle vulnerabilit\u00e0 pi\u00f9 comuni nelle seguenti aree:<\/p>\n\n\n\n Si noti che molti dei laboratori richiedono di enumerare nomi utente e password di forza bruta. Per venirci in aiuto, \u201cPortSwigger Academy<\/a><\/strong>\u201d fornisce un elenco di usernames<\/a> e passwords<\/a> da utilizzare per risolvere i lab.<\/p>\n\n\n\n Vulnerabilit\u00e0 nei meccanismi di autenticazione di terze parti<\/strong><\/p>\n\n\n\n Se si \u00e8 interessati ai meccanismi di autenticazione,\u201cPortSwigger Academy<\/a><\/strong>\u201d consiglia, dopo aver completato i principali laboratori di autenticazione, di provare ad affrontare i loro laboratori di autenticazione OAuth<\/em>.<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n OAuth authentication<\/a><\/p>\n\n\n\n Prevenzione degli attacchi ai propri meccanismi di autenticazione<\/strong><\/p>\n\n\n\n Abbiamo dimostrato diversi modi in cui i siti Web possono essere vulnerabili a causa del modo in cui implementano l\u2019autenticazione. Per ridurre il rischio di tali attacchi sui propri siti web, ci sono diversi principi generali che dovresti sempre cercare di seguire.<\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n How to secure your authentication mechanisms<\/a><\/p>\n\n\n\n (torna su<\/a>)<\/p>\n\n\n\n Vulnerabilit\u00e0 nell\u2019accesso basato su password<\/strong> <\/mark><\/p>\n\n\n\n In questa sezione esamineremo pi\u00f9 da vicino alcune delle vulnerabilit\u00e0 pi\u00f9 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 \u200b\u200bmodo da esercitarsi sullo sfruttamento di tali vulnerabilit\u00e0.<\/p>\n\n\n\n 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 \u00e8 associato a un nome utente univoco e una password segreta, che l\u2019utente inserisce in un modulo di accesso per autenticarsi.<\/p>\n\n\n\n In questo scenario, il semplice fatto di conoscere la password segreta \u00e8 considerato una prova sufficiente dell\u2019identit\u00e0 dell\u2019utente. 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.<\/p>\n\n\n\n Ci\u00f2 pu\u00f2 essere ottenuto in vari modi, come esploreremo di seguito.<\/p>\n\n\n\n Attacchi di forza bruta<\/strong><\/p>\n\n\n\n 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\u2019automazione 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\u00e0.<\/p>\n\n\n\n La forzatura bruta non \u00e8 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\u00f9 plausibili. Ci\u00f2 aumenta notevolmente l\u2019efficienza di tali attacchi. I siti Web che si basano sull\u2019accesso basato su password come unico metodo di autenticazione degli utenti possono essere altamente vulnerabili se non implementano una protezione di forza bruta sufficiente.<\/p>\n\n\n\n Brute-forcing usernames<\/strong><\/p>\n\n\n\n I nomi utente sono particolarmente facili da indovinare se sono conformi a uno schema riconoscibile, come un indirizzo e-mail. Ad esempio, \u00e8 molto comune vedere gli accessi aziendali nel formato nome.cognome@societ\u00e0.com<\/em>. Tuttavia, anche se non esiste uno schema ovvio, a volte vengono creati anche account con privilegi elevati utilizzando nomi utente prevedibili, come admin<\/em> o administrator<\/em>.<\/p>\n\n\n\n Durante l\u2019audit, 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 \u00e8 nascosto, il nome utilizzato nel profilo a volte \u00e8 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.<\/p>\n\n\n\n Brute-forcing passwords<\/strong><\/p>\n\n\n\n Allo stesso modo, le password possono subire attacchi a forza bruta, con difficolt\u00e0 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\u00f9 difficili da decifrare utilizzando la sola forza bruta. Ci\u00f2 comporta in genere l\u2019applicazione delle password con:<\/p>\n\n\n\n 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\u00e0 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\u00e9 si adatti alla politica della password. Ad esempio, se mypassword<\/em> non \u00e8 consentito, gli utenti possono provare qualcosa come Mypassword1!<\/em> o invece Myp4$$w0rd<\/em>.<\/p>\n\n\n\n Nei casi in cui la politica richiede agli utenti di modificare regolarmente le proprie password, \u00e8 anche normale che gli utenti apportino solo modifiche minori e prevedibili alla propria password preferita. Ad esempio, Miapassword1!<\/em> diventa Miapassword1?<\/em> o Miapassword2!<\/em>.<\/p>\n\n\n\n Questa conoscenza delle credenziali probabili e dei modelli prevedibili significa che gli attacchi di forza bruta possono spesso essere molto pi\u00f9 sofisticati, e quindi efficaci, rispetto alla semplice ripetizione di ogni possibile combinazione di caratteri.<\/p>\n\n\n\n Username enumeration<\/strong><\/p>\n\n\n\n L\u2019enumerazione del nome utente \u00e8 quando un utente malintenzionato \u00e8 in grado di osservare i cambiamenti nel comportamento del sito Web per identificare se un determinato nome utente \u00e8 valido.<\/p>\n\n\n\n L\u2019enumerazione 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\u00e0 utilizzato. Ci\u00f2 riduce notevolmente il tempo e lo sforzo necessari per forzare un accesso in quanto l\u2019attaccante \u00e8 in grado di generare rapidamente un elenco ristretto di nomi utente validi.<\/p>\n\n\n\n Durante il tentativo di applicare la forza bruta a una pagina di accesso, dovresti prestare particolare attenzione a eventuali differenze in:<\/p>\n\n\n\n Lab: Username enumeration via different responses<\/a><\/p>\n\n\n\n Lab: Username enumeration via subtly different responses<\/a><\/p>\n\n\n\n Lab: Username enumeration via response timing<\/a><\/p>\n\n\n\n Protezione dalla forza bruta imperfetta<\/strong><\/p>\n\n\n\n \u00c8 molto probabile che un attacco di forza bruta comporti molte ipotesi fallite prima che l\u2019aggressore comprometta con successo un account. Logicamente, la protezione dalla forza bruta ruota attorno al tentativo di rendere il pi\u00f9 complicato possibile l\u2019automazione del processo e rallentare la velocit\u00e0 con cui un utente malintenzionato pu\u00f2 tentare l\u2019accesso. I due modi pi\u00f9 comuni per prevenire gli attacchi di forza bruta sono:<\/p>\n\n\n\n Entrambi gli approcci offrono diversi gradi di protezione, ma nessuno dei due \u00e8 invulnerabile, soprattutto se implementato utilizzando una logica errata.<\/p>\n\n\n\n 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\u00f2 significa che un utente malintenzionato dovrebbe semplicemente accedere al proprio account ogni pochi tentativi per impedire che questo limite venga raggiunto.<\/p>\n\n\n\n In questo caso, \u00e8 sufficiente includere semplicemente le proprie credenziali di accesso a intervalli regolari nell\u2019elenco delle parole per rendere questa difesa praticamente inutile.<\/p>\n\n\n\n Lab: Broken brute-force protection, IP block<\/a><\/p>\n\n\n\n Blocco dell\u2019account<\/strong><\/p>\n\n\n\n Un modo in cui i siti Web tentano di prevenire la forzatura bruta \u00e8 bloccare l\u2019account 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 \u00e8 bloccato possono aiutare un utente malintenzionato a enumerare i nomi utente.<\/p>\n\n\n\n Lab: Username enumeration via account lock<\/a><\/p>\n\n\n\n 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\u2019aggressore tenta semplicemente di accedere a qualsiasi account casuale possibile.<\/p>\n\n\n\n Ad esempio, \u00e8 possibile utilizzare il seguente metodo per aggirare questo tipo di protezione:<\/p>\n\n\n\n Inoltre, il blocco degli account non protegge dagli attacchi di credential stuffing<\/em>. Ci\u00f2 comporta l\u2019utilizzo di un enorme dizionario di coppie nome utente: password<\/em>, 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\u00f9 siti Web e, pertanto, esiste la possibilit\u00e0 che alcune delle credenziali compromesse nel dizionario siano valide anche sul sito Web di destinazione. Il blocco dell\u2019account non protegge dal credential stuffing perch\u00e9 ciascun nome utente viene tentato una sola volta. Il credential stuffing \u00e8 particolarmente pericoloso perch\u00e9 a volte pu\u00f2 portare l\u2019aggressore a compromettere molti account diversi con un solo attacco automatizzato.<\/p>\n\n\n\n User rate limiting<\/strong><\/p>\n\n\n\n Un altro modo in cui i siti Web cercano di prevenire gli attacchi di forza bruta \u00e8 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\u2019IP pu\u00f2 essere sbloccato solo in uno dei seguenti modi:<\/p>\n\n\n\n La limitazione della frequenza degli utenti \u00e8 talvolta preferita al blocco dell\u2019account poich\u00e9 \u00e8 meno incline all\u2019enumerazione dei nomi utente e agli attacchi di negazione del servizio. Tuttavia, non \u00e8 ancora completamente sicuro. Come abbiamo visto in un esempio in un laboratorio precedente, esistono diversi modi in cui un utente malintenzionato pu\u00f2 manipolare il proprio IP apparente per aggirare il blocco.<\/p>\n\n\n\n Poich\u00e9 il limite si basa sulla frequenza delle richieste HTTP inviate dall\u2019indirizzo IP dell\u2019utente, a volte \u00e8 anche possibile aggirare questa difesa se si riesce a indovinare pi\u00f9 password con una singola richiesta.<\/p>\n\n\n\n Lab: Broken brute-force protection, multiple credentials per request<\/a><\/p>\n\n\n\n Autenticazione di base HTTP<\/strong><\/p>\n\n\n\n Sebbene sia piuttosto vecchio, la sua relativa semplicit\u00e0 e facilit\u00e0 di implementazione significa che a volte potresti vedere utilizzata l\u2019autenticazione di base HTTP. Nell\u2019autenticazione 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\u2019intestazione Authorization <\/em>di ogni richiesta successiva come segue:<\/p>\n\n\n\n Per una serie di motivi, questo non \u00e8 generalmente considerato un metodo di autenticazione sicuro. Innanzitutto, comporta l\u2019invio ripetuto delle credenziali di accesso dell\u2019utente ad ogni richiesta. A meno che il sito Web non implementi anche l\u2019HSTS, le credenziali dell\u2019utente possono essere catturate in un attacco man-in-the-middle.<\/p>\n\n\n\n Inoltre, le implementazioni dell\u2019autenticazione di base HTTP spesso non supportano la protezione dalla forza bruta. Poich\u00e9 il token \u00e8 costituito esclusivamente da valori statici, ci\u00f2 pu\u00f2 renderlo vulnerabile alla forza bruta.<\/p>\n\n\n\n L\u2019autenticazione di base HTTP \u00e8 inoltre particolarmente vulnerabile agli exploit legati alla sessione, in particolare CSRF, contro i quali non offre di per s\u00e9 alcuna protezione.<\/p>\n\n\n\n In alcuni casi, lo sfruttamento dell\u2019autenticazione di base HTTP vulnerabile potrebbe garantire a un utente malintenzionato solo l\u2019accesso a una pagina apparentemente poco interessante. Tuttavia, oltre a fornire un\u2019ulteriore superficie di attacco, le credenziali esposte in questo modo potrebbero essere riutilizzate in altri contesti pi\u00f9 riservati.<\/p>\n\n\n\n (torna su<\/a>)<\/p>\n\n\n\n Vulnerabilit\u00e0 nell\u2019autenticazione a pi\u00f9 fattori<\/mark><\/strong><\/p>\n\n\n\n In questa sezione esamineremo alcune delle vulnerabilit\u00e0 che possono verificarsi nei meccanismi di autenticazione a pi\u00f9 fattori. Ci sono anche diversi laboratori interattivi per dimostrare come sfruttare queste vulnerabilit\u00e0 nell\u2019autenticazione a pi\u00f9 fattori.<\/p>\n\n\n\n Molti siti Web si affidano esclusivamente all\u2019autenticazione a fattore singolo utilizzando una password per autenticare gli utenti. Tuttavia, alcuni richiedono agli utenti di dimostrare la propria identit\u00e0 utilizzando pi\u00f9 fattori di autenticazione.<\/p>\n\n\n\n La verifica dei fattori biometrici non \u00e8 pratica per la maggior parte dei siti web. Tuttavia, \u00e8 sempre pi\u00f9 comune vedere l\u2019autenticazione a due fattori (2FA) sia obbligatoria che facoltativa basata su qualcosa che conosci e qualcosa che possiedi. Ci\u00f2 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.<\/p>\n\n\n\n Token di autenticazione a due fattori<\/strong><\/p>\n\n\n\n I codici di verifica vengono solitamente letti dall\u2019utente 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. \u00c8 anche comune che i siti Web utilizzino un\u2019app mobile dedicata, come Google Authenticator, per lo stesso motivo.<\/p>\n\n\n\n Alcuni siti web, invece, inviano i codici di verifica al cellulare dell\u2019utente sotto forma di messaggio di testo. Anche se tecnicamente questo sta ancora verificando il fattore \u201cqualcosa che hai\u201d, \u00e8 aperto ad abusi. Innanzitutto, il codice viene trasmesso tramite SMS anzich\u00e9 essere generato dal dispositivo stesso. Ci\u00f2 crea la possibilit\u00e0 che il codice venga intercettato. Esiste anche il rischio di SIM Swapping, per cui l\u2019aggressore si procura in modo fraudolento una carta SIM con il numero di telefono della vittima. L\u2019aggressore riceverebbe quindi tutti i messaggi SMS inviati alla vittima, compreso quello contenente il codice di verifica.<\/p>\n\n\n\n Bypassare l\u2019autenticazione a due fattori<\/strong><\/p>\n\n\n\n A volte, l\u2019implementazione dell\u2019autenticazione a due fattori \u00e8 viziata al punto che pu\u00f2 essere completamente aggirata.<\/p>\n\n\n\n Se all\u2019utente viene prima richiesto di inserire una password e poi un codice di verifica in una pagina separata, l\u2019utente si trova effettivamente in uno stato di \u201caccesso\u201d prima di aver inserito il codice di verifica. In questo caso, vale la pena verificare se \u00e8 possibile passare direttamente alle pagine \u201csolo loggato\u201d dopo aver completato il primo passaggio di autenticazione. Occasionalmente, scoprirai che un sito Web in realt\u00e0 non controlla se hai completato o meno il secondo passaggio prima di caricare la pagina.<\/p>\n\n\n\n Lab: 2FA simple bypass<\/a><\/p>\n\n\n\n Logica di verifica a due fattori difettosa<\/strong><\/p>\n\n\n\n La logica difettosa nell\u2019autenticazione 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.<\/p>\n\n\n\n Ad esempio, l\u2019utente accede con le normali credenziali nel primo passaggio come segue:<\/p>\n\n\n\n Gli viene quindi assegnato un cookie relativo all\u2019account, prima di essere portato alla seconda fase del processo di accesso:<\/p>\n\n\n\n Quando si invia il codice di verifica, la richiesta utilizza questo cookie per determinare a quale account l\u2019utente sta tentando di accedere:<\/p>\n\n\n\n n questo caso, un utente malintenzionato potrebbe accedere utilizzando le proprie credenziali, ma poi modificare il valore del cookie dell\u2019account con qualsiasi nome utente arbitrario quando invia il codice di verifica.<\/p>\n\n\n\n Ci\u00f2 \u00e8 estremamente pericoloso se l\u2019aggressore \u00e8 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\u2019utente.<\/p>\n\n\n\n Lab: 2FA broken logic<\/a><\/p>\n\n\n\n Brute-forcing codici di verifica 2FA<\/strong><\/p>\n\n\n\n Come per le password, i siti web devono adottare misure per impedire la forzatura bruta del codice di verifica 2FA. Ci\u00f2 \u00e8 particolarmente importante perch\u00e9 il codice \u00e8 spesso un semplice numero di 4 o 6 cifre. Senza un\u2019adeguata protezione dalla forza bruta, decifrare un codice del genere \u00e8 banale. Lab: 2FA bypass using a brute-force attack<\/a><\/p>\n\n\n\n (torna su<\/a>)<\/p>\n\n\n\n Vulnerabilit\u00e0 in altri meccanismi di autenticazione<\/strong> <\/mark><\/p>\n\n\n\n In questa sezione esamineremo alcune delle funzionalit\u00e0 supplementari correlate all\u2019autenticazione e dimostreremo come queste possano essere vulnerabili. Vi sono anche diversi laboratori interattivi che possono essere utilizzati per mettere in pratica l’argomento.<\/p>\n\n\n\n Oltre alla funzionalit\u00e0 di accesso di base, la maggior parte dei siti Web fornisce funzionalit\u00e0 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\u00e0 che possono essere sfruttate da un utente malintenzionato.<\/p>\n\n\n\n I siti web di solito fanno attenzione a evitare vulnerabilit\u00e0 ben note nelle loro pagine di accesso. Ma \u00e8 facile trascurare il fatto che \u00e8 necessario adottare misure simili per garantire che le funzionalit\u00e0 correlate siano altrettanto robuste. Ci\u00f2 \u00e8 particolarmente importante nei casi in cui un utente malintenzionato \u00e8 in grado di creare il proprio account e, di conseguenza, ha un facile accesso per studiare queste pagine aggiuntive.<\/p>\n\n\n\n Mantenere gli utenti connessi<\/strong><\/p>\n\n\n\n Una caratteristica comune \u00e8 la possibilit\u00e0 di rimanere connesso anche dopo aver chiuso una sessione del browser. Di solito si tratta di una semplice casella etichettata come \u201cRicordami\u201d o \u201cResta connesso\u201d.<\/p>\n\n\n\n Questa funzionalit\u00e0 viene spesso implementata generando un token \u201cricordami\u201d di qualche tipo, che viene quindi archiviato in un cookie persistente. Poich\u00e9 il possesso di questo cookie consente effettivamente di bypassare l\u2019intero processo di accesso, \u00e8 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 \u00e8 particolarmente pericoloso se un utente malintenzionato \u00e8 in grado di creare il proprio account perch\u00e9 pu\u00f2 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\u2019accesso ai loro account.<\/p>\n\n\n\n Alcuni siti Web presumono che se il cookie \u00e8 crittografato in qualche modo non sar\u00e0 individuabile anche se utilizza valori statici. Sebbene ci\u00f2 possa essere vero se eseguito correttamente, la \u201ccrittografia\u201d ingenua del cookie utilizzando una semplice codifica bidirezionale come Base64 non offre alcuna protezione di sorta. Anche l\u2019utilizzo di una crittografia adeguata con una funzione hash unidirezionale non \u00e8 completamente a prova di bomba. Se l\u2019aggressore \u00e8 in grado di identificare facilmente l\u2019algoritmo di hashing e non viene utilizzato alcun salt<\/em>, pu\u00f2 potenzialmente forzare il cookie semplicemente eseguendo l\u2019hashing dei propri elenchi di parole. Questo metodo pu\u00f2 essere utilizzato per aggirare i limiti dei tentativi di accesso se un limite simile non viene applicato alle ipotesi sui cookie.<\/p>\n\n\n\n Lab: Brute-forcing a stay-logged-in cookie<\/a><\/p>\n\n\n\n Anche se l\u2019aggressore non \u00e8 in grado di creare il proprio account, potrebbe comunque riuscire a sfruttare questa vulnerabilit\u00e0. Utilizzando le tecniche consuete, come XSS, un utente malintenzionato potrebbe rubare il cookie \u201cricordami\u201d di un altro utente e dedurre da quello come \u00e8 costruito il cookie. Se il sito web \u00e8 stato creato utilizzando un framework open source, i dettagli chiave della costruzione dei cookie potrebbero anche essere documentati pubblicamente.<\/p>\n\n\n\n In alcuni rari casi, potrebbe essere possibile ottenere la password effettiva di un utente in chiaro da un cookie, anche se \u00e8 sottoposta ad hashing. Online sono disponibili versioni con hash di elenchi di password noti, quindi se la password dell\u2019utente appare in uno di questi elenchi, decodificare l\u2019hash a volte pu\u00f2 essere banale come semplicemente incollarlo in un motore di ricerca. Ci\u00f2 dimostra l\u2019importanza del salt <\/em>in una crittografia efficace.<\/p>\n\n\n\n Lab: Offline password cracking<\/a><\/p>\n\n\n\n Reimpostazione delle password degli utenti<\/strong><\/p>\n\n\n\n In pratica, \u00e8 un dato di fatto che alcuni utenti dimenticheranno la propria password, quindi \u00e8 normale avere un modo per reimpostarla. Poich\u00e9 in questo scenario la consueta autenticazione basata su password \u00e8 ovviamente impossibile, i siti Web devono fare affidamento su metodi alternativi per assicurarsi che l\u2019utente reale reimposti la propria password. Per questo motivo, la funzionalit\u00e0 di reimpostazione della password \u00e8 intrinsecamente pericolosa e deve essere implementata in modo sicuro.<\/p>\n\n\n\n Esistono diversi modi in cui questa funzionalit\u00e0 viene comunemente implementata, con diversi gradi di vulnerabilit\u00e0.<\/p>\n\n\n\n Invio password tramite e-mail<\/strong><\/p>\n\n\n\n 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\u2019utente tramite e-mail.<\/p>\n\n\n\n In generale \u00e8 da evitare l\u2019invio 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\u2019utente. Altrimenti, questo approccio \u00e8 altamente suscettibile agli attacchi man-in-the-middle.<\/p>\n\n\n\n Anche la posta elettronica non \u00e8 generalmente considerata sicura dato che le caselle di posta sono persistenti e non realmente progettate per l\u2019archiviazione sicura di informazioni riservate. Molti utenti inoltre sincronizzano automaticamente la propria casella di posta tra pi\u00f9 dispositivi attraverso canali non sicuri.<\/p>\n\n\n\n Reimpostazione delle password utilizzando un URL<\/strong><\/p>\n\n\n\n Un metodo pi\u00f9 efficace per reimpostare le password consiste nell\u2019inviare 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: <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Un\u2019implementazione migliore di questo processo consiste nel generare un token ad alta entropia difficile da indovinare e creare l\u2019URL di reimpostazione basato su quello. Nella migliore delle ipotesi, questo URL non dovrebbe fornire suggerimenti su quale password dell\u2019utente viene reimpostata.<\/p>\n\n\n\n Quando l\u2019utente visita questo URL, il sistema dovrebbe verificare se questo token esiste sul back-end e, in tal caso, quale password dell\u2019utente deve reimpostare. Questo token dovrebbe scadere dopo un breve periodo di tempo ed essere distrutto immediatamente dopo la reimpostazione della password.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Lab: Password reset broken logic<\/a><\/p>\n\n\n\n Se l\u2019URL nell\u2019e-mail di reimpostazione viene generato dinamicamente, anche questo potrebbe essere vulnerabile all\u2019avvelenamento da reimpostazione della password. In questo caso, un utente malintenzionato pu\u00f2 potenzialmente rubare il token di un altro utente e utilizzarlo per modificare la propria password.<\/p>\n\n\n\n Lab: Password reset poisoning via middleware<\/a><\/p>\n\n\n\n Per saperne di pi\u00f9<\/strong><\/p>\n\n\n\n Password reset poisoning<\/a><\/p>\n\n\n\n Modifica delle password degli utenti<\/strong><\/p>\n\n\n\n In genere, la modifica della password comporta l\u2019immissione 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.<\/p>\n\n\n\n La funzionalit\u00e0 di modifica della password pu\u00f2 essere particolarmente pericolosa se consente a un utente malintenzionato di accedervi direttamente senza aver effettuato l\u2019accesso 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\u00f2 essere potenzialmente sfruttato per enumerare nomi utente e password a forza bruta.<\/p>\n\n\n\n Lab: Password brute-force via password change<\/a><\/p>\n\n\n\n (torna su<\/a>)<\/p>\n","protected":false},"excerpt":{"rendered":" PortSwigger Academy \u2013 Authentication Continua il percorso di apprendimento suggerito da \u201cPortSwigger Academy\u201d. Consiglio di iscriversi alla piattaforma, seguire le lezioni e soprattutto svolgere e completare i lab \ud83d\ude42 Authentication Authentication vulnerabilities Almeno concettualmente, le vulnerabilit\u00e0 dell\u2019autenticazione sono alcuni dei problemi pi\u00f9 semplici da comprendere. Tuttavia, possono essere tra i pi\u00f9 critici a causa dell\u2019ovvia … Leggi tutto “Authentication”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2,"footnotes":""},"categories":[5,15],"tags":[],"class_list":["post-1101","post","type-post","status-publish","format-standard","hentry","category-burp-suite","category-ethical-hacking"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/1101","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=1101"}],"version-history":[{"count":38,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/1101\/revisions"}],"predecessor-version":[{"id":2028,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/1101\/revisions\/2028"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=1101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=1101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=1101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/lh6.googleusercontent.com\/uHaTkQonOwu5mc6PCPLGG9D-2zvqzDQuDnGQ-1Se9BTiRowNU2V-7kHpuNkWiXtaKBHsKKymMBDqR5HXHY1mciWg7RXebSNqlJRGc6cqdr8pj191eWeTdPdK9sKkb5fDl-ePBHyWfNBopyl45a5HcII\")
\n
\n
\n
\n
\n
\n
\n
\n
Authorization: Basic base64(username:password)<\/em><\/code><\/pre>\n\n\n\nPOST \/login-steps\/first HTTP\/1.1\nHost: vulnerable-website.com\n...\nusername=carlos&password=qwerty<\/em><\/code><\/pre>\n\n\n\nHTTP\/1.1 200 OK\nSet-Cookie: account=carlos\n\nGET \/login-steps\/second HTTP\/1.1\nCookie: account=carlos<\/em><\/code><\/pre>\n\n\n\nPOST \/login-steps\/second HTTP\/1.1\nHost: vulnerable-website.com\nCookie: account=carlos\n...\nverification-code=123456<\/em><\/code><\/pre>\n\n\n\nPOST \/login-steps\/second HTTP\/1.1\nHost: vulnerable-website.com\nCookie: account=victim-user\n...\nverification-code=123456<\/em><\/code><\/pre>\n\n\n\n
Alcuni siti Web tentano di impedire ci\u00f2 disconnettendo automaticamente un utente se inserisce un certo numero di codici di verifica errati. Ci\u00f2 \u00e8 inefficace nella pratica perch\u00e9 un utente malintenzionato avanzato pu\u00f2 persino automatizzare questo processo in pi\u00f9 fasi creando macro<\/a> per Burp Intruder. A questo scopo \u00e8 possibile utilizzare anche l\u2019estensione Turbo Intruder<\/a>.<\/p>\n\n\n\nhttp:\/\/vulnerable-website.com\/reset-password?user=victim-user<\/em><\/code><\/pre>\n\n\n\nhttp:\/\/vulnerable-website.com\/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8<\/em><\/code><\/pre>\n\n\n\n