Autore: Marc Olivier Bergeron | Pubblicazione originale: 29/06/2022 | Tradotto da: 31febbraio | Milano Trustless | Link: Did You Know Your Browser’s Autofill Credentials Could Be Stolen via Cross-Site Scripting (XSS)
Il Cross-Site Scripting (XSS) è una vulnerabilità ben nota che esiste da molto tempo e che può essere utilizzata per rubare sessioni, creare login falsi ed eseguire azioni 'impersonando' qualcun altro.
Inoltre, molti utenti non sono consapevoli dei potenziali pericoli associati alla funzione di riempimento automatico delle credenziali con il proprio browser. Questo vettore di attacco non è nuovo, ma è sconosciuto a molte persone e, indagando più a fondo, abbiamo scoperto che i pericoli sono molto estesi. In questo post, il team di GoSecure Titan Labs dimostrerà che l'utilizzo di un gestore di password del browser con l'autofill può esporre le vostre credenziali in un'app web vulnerabile agli XSS.
Analisi
Il problema
La maggior parte dei browser ha aggiunto una funzione comunemente chiamata 'autofill' o 'compilazione automatica' che facilita il processo di login per le applicazioni web. Questa funzione consente di inserire automaticamente le credenziali salvate per una determinata applicazione web senza alcuna interazione. Questa funzione è impostata come predefinita sulla maggior parte dei browser comunemente utilizzati, come Firefox, Chrome, Edge, Opera, Internet Explorer, e talvolta non può essere disattivata. Ciò significa che non c'è modo di impedire il riempimento automatico delle credenziali nei browser basati su Chromium, come Chrome ed Edge, poiché non esiste un'opzione per disabilitarlo. L'unico modo per impedire la compilazione automatica su questi browser è quello di non salvare affatto le credenziali. Per questi browser è una situazione del tipo "tutto o niente". Pertanto, anche se si disattiva il 'salvataggio delle password' ma le credenziali sono ancora salvate, questi browser continueranno a eseguire il riempimento automatico.
Ora, perché questo è un problema e come può essere rubato con un attacco XSS? Quando il browser trova, in qualsiasi momento, un tag di input di tipo 'password', lo riempie automaticamente con una password. Pertanto, con un attacco XSS, si può semplicemente aggiungere un campo password da qualche parte nel corpo della pagina, attendere che il browser lo riempia automaticamente e quindi recuperare il valore all'interno del campo per inviarlo al server.
Naturalmente, la tecnica sopra descritta sembra facile da eseguire, ma non è così semplice perché dipende da molte variabili, come ad esempio se la vittima ha salvato le credenziali per quell'origine, quale browser utilizza, quante credenziali ha salvato per quell'origine e se ha attivato l'opzione di riempimento automatico. Va notato che anche i password manager possono essere colpiti da questo vettore di attacco se l'autofill è abilitato, cosa che non è predefinita nella maggior parte di questi manager.
Inoltre, questo vettore di attacco non è nuovo e dopo che è stato trovato, è stato facile identificarlo come altri blog che ne parlano brevemente. L'obiettivo è dare maggiore visibilità a questo vettore di attacco e aiutare le persone a capire l'impatto dell'utilizzo di riempimento automatico, che è abilitato per impostazione predefinita sulla maggior parte dei browser. L'ambiente in cui è stato testato è stato il più realistico possibile, ovvero in HTTPS con un certificato valido.
Vettore di attacco
Passiamo ora alla parte in cui sarà possibile vedere quanto sia facile rubare le credenziali con un semplice attacco XSS. Innanzitutto, ecco come reagisce Firefox quando si aggiunge un campo di input con tipo uguale a "password" in qualsiasi punto della pagina (con un solo set di credenziali):
Considerando che la vittima dispone di una serie di credenziali su Firefox per una determinata origine, creiamo un payload funzionante per estrarre la password.
E in azione:
Ora, lo stesso esperimento ma con due serie di credenziali:
Quindi, con due serie di credenziali su Firefox, non ha compilato automaticamente nessuna delle credenziali. E cosa succede con Chrome?
Sembra che Chrome riempia il campo della password solo se prima di esso è presente un campo del nome utente; come si può vedere nella prima immagine, non ha riempito il campo della password. Si noti che i browser Edge e Opera hanno reagito allo stesso modo di Chrome.
Ora proviamo a estrarre le credenziali con lo stesso payload di Firefox.
Come si può vedere, le credenziali non sono accessibili, il che è piuttosto strano. Dopo alcune ricerche, ci siamo imbattuti in un post sul blog che, in poche parole, spiega che Chrome richiede un'interazione nella finestra per incollare i valori. Ciò significa che per Chrome, e per gli altri basati sullo stesso motore, è necessaria un'interazione come un clic o la pressione di un tasto. Pertanto, il payload deve essere adattato in modo che, invece di utilizzare un timeout, utilizzi un'interazione dell'utente di qualche tipo. Per semplicità, utilizziamo l'evento "on-click" sul campo, in modo che ogni volta che la vittima clicca sulla pagina per seguire un link o concentrarsi su qualcosa, il payload venga eseguito.
Questa tecnica funziona. Dopo un clic nella pagina, il payload viene eseguito e le credenziali vengono inviate al server malevolo. Proprio come in Firefox, qual è il risultato di avere più set di credenziali in Chrome?
Chrome imposta i campi sull'ultimo set di credenziali utilizzato. Ma è possibile ottenere gli altri set di credenziali? Che ne dite di ottenere un set di credenziali con Firefox con più set? La password viene compilata automaticamente in base al nome utente nel campo precedente? Proviamo con Firefox:
Il riempimento automatico avviene come ci aspettavamo. E Chrome? Si comporta allo stesso modo?
Effettua anche lui il riempimento automatico. Ciò significa che è possibile enumerare tutte le credenziali salvate se il nome utente corrisponde.
Differenze tra i browser
Ogni browser è diverso dall'altro, perché non si basa sullo stesso motore o offre funzioni di sicurezza aggiunte per impedire l'autocompilazione delle credenziali. Brave è un esempio di browser basato su Chromium, ma non prevede l'autocompilazione delle credenziali.
La serie di grafici che segue vi aiuterà a comprendere meglio la sicurezza dei browser e le funzioni di autofill con un'analisi.
Firefox
Ha l'opzione di disabilitare l'autofill? |
Sì |
Si può ricaricare automaticamente? |
Sì |
Compilazione automatica su corrispondenza esatta (una o più credenziali salvate)? |
Sì |
La versione mobile si comporta alla stessa maniera? |
Sì |
L'aspetto positivo di Firefox è che è possibile disattivare l'opzione di autocompilazione e utilizzare comunque la funzione di gestione delle password. Una volta disattivata, richiede un'interazione per mostrare un pop-up contenente i set di credenziali corrispondenti a quell'origine. Tuttavia, questa opzione è abilitata per impostazione predefinita. Va notato che anche il browser Tor è basato sullo stesso motore di Firefox, ma non chiede di salvare le password per impostazione predefinita e non effettua la compilazione automatica. Inoltre, il browser Tor su cellulare richiede il 'salvataggio della password' e di riempimento automatico per impostazione predefinita. Tuttavia, dalle nostre ricerche e dai nostri test, non funziona più poiché Tor apre sempre una scheda privata e quindi non conserva alcuna informazione e non chiede di salvare le password. Inoltre, il browser Tor ha una protezione aggiuntiva che blocca gli script se non autorizzati.
Browser basati su Chromium (Chrome, Edge, Opera)
Ha l'opzione di disabilitare l'autofill? |
Sì |
Si può ricaricare automaticamente? |
Sì |
Compilazione automatica su corrispondenza esatta (una o più credenziali salvate)? |
Sì |
La versione mobile si comporta alla stessa maniera? (Chrome, Edge) |
No |
La versione mobile si comporta alla stessa maniera? (Opera) |
Sì |
Solo Chrome, Edge e Opera sono stati testati a fondo, ma ci sono altri browser basati suChromium che non sono stati testati perché non sono molto utilizzati. In questi browser non esiste un'opzione per disabilitare l'autofill e anche se la funzione di 'salvare le password' è disabilitata, se esiste un set di credenziali corrispondenti salvate per quell'origine, l'autofill verrà eseguito. È interessante notare che le versioni mobili dei browser Chrome ed Edge non reagiscono allo stesso modo della versione desktop. Le versioni mobili non effettuano alcuna autocompilazione e richiedono un'interazione per mostrare un popup contenente i set di credenziali corrispondenti per quell'origine.
Brave
Ha l'opzione di disabilitare l'autofill? |
No |
Si può ricaricare automaticamente? |
No |
Compilazione automatica su corrispondenza esatta (una o più credenziali salvate)? |
No |
La versione mobile si comporta alla stessa maniera? |
Sì |
Anche Brave è basato su Chromium, ma non si comporta come gli altri. Non esegue il riempimento automatico, in nessun caso, il che impedisce questo vettore di attacco XSS per il furto di credenziali. Invece, richiede un'interazione per mostrare un popup contenente i set di credenziali corrispondenti per quell'origine.
Internet Explorer
Ha l'opzione di disabilitare l'autofill? |
Sì |
Si può ricaricare automaticamente? |
Sì |
Compilazione automatica su corrispondenza esatta (una o più credenziali salvate)? |
Sì |
La versione mobile si comporta alla stessa maniera? |
N/D |
Contro ogni aspettativa, Internet Explorer sembra essere più sicuro della maggior parte dei browser basati su Chromium, poiché esiste un'opzione per disabilitare l'autocompilazione delle credenziali. Tuttavia, se si disattiva questa opzione, non è più possibile utilizzare la funzione 'salva credenziali'. L'opzione è attiva di default.
Safari
Ha l'opzione di disabilitare l'autofill? |
Sì |
Si può ricaricare automaticamente? |
No |
Compilazione automatica su corrispondenza esatta (una o più credenziali salvate)? |
No |
La versione mobile si comporta alla stessa maniera? |
Sì |
Safari ha l'opzione di disabilitare l'autofill, ma non lo esegue in nessun caso. Richiede un'interazione per mostrare un popup contenente i set di credenziali corrispondenti per quell'origine.
Protezione
Per gli sviluppatori Web
Non esiste una vera e propria soluzione a questo problema, ma ci sono alcune cose che si possono fare per prevenire il Cross-Site Scripting (XSS). Innanzitutto, una buona intestazione Content-Security Policy (CSP) aiuterà a prevenire l'esecuzione di script malevoli e quindi a rendere gli attacchi XSS più difficili da sfruttare. Detto questo, tenete presente che la configurazione del CSP aiuta solo a prevenire gli attacchi XSS e che ci sono molti modi per aggirarli a seconda della configurazione. In secondo luogo, assicurandosi che i dati riportati in una pagina siano codificati, convalidati o resi innocui dal codice HTML.
Per gli amministratori della cyber-security
Una soluzione potrebbe essere quella di disabilitare il salvataggio delle password del browser tramite Group Policy Object (GPO) o Endpoint Manager. In questo modo si impedisce agli utenti di salvare le proprie credenziali con la funzione di gestione delle password del browser. Tuttavia, tutte le password aggiunte in precedenza verranno comunque compilate automaticamente, a seconda del browser e se la funzione è ancora abilitata.
Per gli utenti
Esistono due soluzioni valide per gli utenti finali che desiderano utilizzare un gestore di password, utile in presenza di una lista di siti web in continua espansione e di password che devono essere uniche. La prima, e migliore soluzione, è quella di utilizzare un vero e proprio gestore di password, come KeePass o soluzioni commerciali simili come 1Password o Bitwarden, che sia rinomato, testato e che non abbia l'autofill di default. Assicuratevi che il vostro gestore di password non compili automaticamente le credenziali in modo che non possano essere recuperate automaticamente da un attacco XSS senza interazione. La seconda soluzione consiste nell'utilizzare un browser che non prevede il riempimento automatico per impostazione predefinita o che consente di disabilitare il riempimento automatico per le password salvate.
Conclusione
Questo vettore di attacco non è affatto nuovo, ma è interessante vedere come molti browser comunemente utilizzati siano vulnerabili per impostazione predefinita. Ci auguriamo che questo possa aumentare la consapevolezza del problema e aiutare gli utenti non tecnici a passare a soluzioni migliori, come un gestore di password o un browser più flessibile, attento alla sicurezza e facile da usare. Se volete saperne di più sui nostri risultati e su argomenti simili, ricordate di seguire GoSecure su Twitter e LinkedIn per le ultime ricerche.
Un ringraziamento speciale a Simon Bouchard per i test iOS e mobile e a Lisandro Ubiedo per i test Tor.
Se non diversamente specificato, il contenuto di questo articolo è concesso in licenza ai sensi del CC BY-SA 4.0
Milano Trustless (31febbraioMI)
#MilanoTrustless è un progetto personale per #orangepillare 🟠💊 Milano e infondere ai (meravigliosi) milanesi la mentalità #trustless
follow me :
Related Posts
Personal Server - How to setup and configure
Jun 09, 2024
Come iniziare con LIGHTNING NETWORK
Aug 03, 2023
Die Bitcoin-Angebotsformel erklärt
Jun 05, 2023