Come un escape del bordo CSS ha compromesso le interfacce webmail più affidabili al mondo

Ricordo di essere stato seduto in un Security Operations Center senza finestre tre anni fa, guardando un red teamer bypassare un web application firewall da milioni di dollari con un singolo carattere codificato. È stato un umiliante promemoria del fatto che la complessità è il nemico della sicurezza. Spesso presumiamo che più spendiamo per uno strato difensivo, più sicura sia la sua protezione. Questa convinzione è un errore. Una recente ricerca presentata da Gareth Heyes di PortSwigger al Black Hat USA 2026 dimostra che anche le piattaforme webmail più mature sono vulnerabili agli attacchi basati sullo stile.

I fornitori di webmail come Gmail, Outlook e Proton Mail spendono milioni in motori di sanitizzazione. Questi sistemi agiscono come un buttafuori di un club VIP a ogni porta interna. Scansionano ogni email HTML in arrivo alla ricerca di script dannosi e tag pericolosi. Se un pezzo di codice sembra sospetto, il sanitizzatore lo rimuove. Questa ricerca mostra che un attaccante non ha bisogno di JavaScript per causare danni. Ha solo bisogno dei Cascading Style Sheets (CSS). Sfruttando il modo in cui i browser e i client webmail interpretano lo stile, un attaccante può saltare la recinzione tra un'email non attendibile e l'interfaccia dell'applicazione attendibile.

Il paradosso architettonico della sanitizzazione delle email

Il problema fondamentale è il confine. Quando apri un'email, il client webmail inserisce quel contenuto non attendibile all'interno della propria interfaccia utente (UI) attendibile. C'è un sottile muro tra il messaggio e i tuoi pulsanti "Posta in arrivo" o "Impostazioni". Di solito, questo muro è una serie di filtri che impediscono all'email di influenzare il resto della pagina. Questa ricerca dimostra come il CSS possa attraversare quel muro.

Un percorso prevede l'abuso di HTML e CSS che il sanitizzatore già consente. L'altro percorso crea una discrepanza tra ciò che il sanitizzatore approva e ciò che il browser alla fine renderizza. Entrambi i percorsi portano allo stesso risultato. Il contenuto dell'email interferisce con l'interfaccia webmail. Ciò può portare al furto di password, alla fuga di token e ad azioni non autorizzate sull'interfaccia utente. Si tratta di un fallimento sistemico del modello di isolamento su cui abbiamo fatto affidamento per decenni.

La catena di cattura delle password di Outlook

La scoperta più drammatica riguarda Outlook e Firefox. Questa catena di attacco è una lezione magistrale nel combinare comportamenti minori del browser per ottenere una compromissione critica. Il ricercatore ha utilizzato elementi label consentiti per attivare controlli all'esterno del messaggio email. Quindi, un trucco di analisi delle media-query ha permesso l'iniezione di CSS arbitrario che il sanitizzatore aveva mancato.

All'interno dell'email, l'attaccante maschera un elemento select standard come una schermata di accesso Microsoft. È qui che entra in gioco il comportamento di Firefox. Firefox ha un timer interno di circa un secondo per i menu di selezione. Se l'elemento select si sposta fuori dallo schermo, il browser resetta questo timer. Spostando l'elemento strategicamente, l'attaccante fa in modo che la cattura avvenga in tempo reale. Quando un utente pensa di digitare la propria password in un prompt attendibile, la sta effettivamente fornendo direttamente all'attaccante. Questa tecnica bypassa i tradizionali avvisi di phishing perché l'URL nella barra degli indirizzi è ancora outlook.live.com.

La "paste race" di Yahoo e AOL

Yahoo Mail e AOL Mail hanno rivelato una vulnerabilità diversa radicata nel modo in cui i browser gestiscono gli appunti. In Firefox, l'HTML incollato può mantenere brevemente il CSS attivo prima che il sanitizzatore dell'applicazione abbia la possibilità di pulirlo. Questa è una "corsa all'incolla" (paste race). La ricerca lo ha dimostrato prendendo di mira i token di accesso via email di Medium.

In questo scenario, l'attaccante avvia un flusso di accesso per l'account Medium della vittima. La vittima riceve una legittima email di accesso. Tuttavia, l'attaccante ha già inviato un'email separata contenente CSS dannoso. La vittima copia questo contenuto e lo incolla in una bozza in Yahoo o AOL. Durante quel frazione di secondo dell'incolla, il CSS dannoso effettua richieste al server dell'attaccante. Queste richieste rivelano abbastanza caratteri del token di accesso a 12 cifre affinché il server possa ricostruire il codice completo. L'attaccante usa quindi quel token per accedere come vittima. L'intero processo si basa su una race condition che si verifica in un batter d'occhio.

Esfiltrazione di token tramite prompt injection

L'ascesa di strumenti email connessi all'IA crea una nuova superficie di attacco. Gmail fornisce un chiaro esempio attraverso il suo comportamento di fallback image-set(). Nonostante gli sforzi di sanitizzazione, questa funzione CSS può ancora effettuare richieste esterne. Gareth Heyes e Pete Hendy hanno concatenato questo con un attacco di prompt injection indiretto. Questo ha preso di mira specificamente gli utenti dello strumento Claude Cowork di Anthropic, che si connette a Gmail per elaborare i messaggi.

Un attaccante invia un'email con istruzioni nascoste per l'IA. Quando la vittima chiede a Claude di elaborare le sue email recenti, l'IA segue le istruzioni iniettate invece del comando dell'utente. Nella dimostrazione, l'IA ha recuperato un token Slack da un'email di conferma separata e lo ha inserito in una nuova bozza HTML. Quando la vittima ha visualizzato quella bozza, il bypass image-set() ha esfiltrato il token verso l'attaccante. Questa evoluzione degli eventi mostra come gli agenti IA possano diventare un cavallo di Troia digitale all'interno di un ambiente sicuro.

Fastmail e l'arte del CSS hotwiring

Fastmail era vulnerabile a quello che il ricercatore chiama "CSS hotwiring". Questa tecnica reindirizza i clic in azioni dell'interfaccia utente multi-step non intenzionali. Utilizzando pseudo-elementi CSS e opacità, un attaccante può sovrapporre pulsanti invisibili sopra l'interfaccia legittima di Fastmail. Un utente che pensa di cliccare su un link in un'email potrebbe in realtà cliccare su un pulsante che cancella la sua posta in arrivo o cambia le impostazioni del suo account.

Questa ricerca ha anche preso di mira il browser IA Atlas di OpenAI. Un attaccante può usare il CSS per mostrare una cosa a un umano e un'altra a una macchina. Ad esempio, l'umano vede un paragrafo di testo innocuo. Il modello IA legge istruzioni nascoste codificate nel CSS. Quando l'utente chiede ad Atlas di tradurre il testo visibile, le istruzioni nascoste causano l'apertura di nuove schede nel browser e la fuga del nome della vittima nei frammenti URL. Sebbene OpenAI stia dismettendo Atlas il 9 agosto 2026, la tecnica rimane un avvertimento per qualsiasi sviluppatore che costruisca IA che interagisce con il web.

Fughe di privacy in Proton Mail

Nemmeno i servizi focalizzati sulla privacy come Proton Mail sono immuni. Il ricercatore ha dimostrato un vettore che esponeva l'indirizzo IP di un destinatario. Proton Mail è progettato per nascondere queste informazioni ai mittenti tramite la protezione dai tracker. Tuttavia, uno specifico bypass CSS ha permesso l'attivazione di una richiesta esterna all'apertura dell'email. Ciò ha rivelato l'ora esatta in cui l'email è stata letta e l'indirizzo IP personale dell'utente. Proton ha da allora affrontato alcuni bypass del proxy, ma la ricerca evidenzia la difficoltà di mantenere un perimetro perfetto in un mondo di CSS complessi.

Rafforzare la webmail contro gli attacchi basati sullo stile

Questi risultati suggeriscono che il nostro attuale approccio alla sicurezza delle email è reattivo. Aspettiamo che un ricercatore trovi un bypass e poi applichiamo una patch. Per i fornitori di webmail, la guida difensiva è ora molto più rigorosa. La difesa più efficace è l'isolamento totale. Ciò significa renderizzare le email HTML all'interno di iframe sandbox. Questo impedisce allo stile dell'email di raggiungere mai l'interfaccia utente principale.

I fornitori devono anche limitare le proprietà CSS a una rigorosa lista consentita di caratteri sicuri. Dovrebbero bloccare i menu di selezione, gli attributi personalizzati e i selettori pericolosi come :has(). Inoltre, devono impedire tutte le richieste di immagini controllate dall'attaccante, anche quelle che sembrano provenire da domini in lista consentita. Dal punto di vista dell'utente finale, la migliore difesa è una sana paranoia. Diffidate di qualsiasi email che vi chieda di copiare e incollare contenuti o di interagire con elementi insoliti dell'interfaccia utente.

Punti chiave per i team di sicurezza

• Implementare il sandboxing rigoroso tramite iframe per tutti i contenuti HTML non attendibili.
• Validare il CSS rispetto a una lista consentita basata sui caratteri piuttosto che a una lista di blocco basata sui tag.
• Controllare l'interazione tra gli assistenti IA e il DOM dell'email per prevenire la prompt injection indiretta.
• Disabilitare le funzionalità CSS pericolose come image-set() e gli pseudo-selettori complessi nel corpo dell'email.
• Rivedere il comportamento degli attributi HTML personalizzati che JavaScript potrebbe successivamente trasformare in elementi attivi.

Fonti:

• PortSwigger Research: Gareth Heyes, Black Hat USA 2026 Paper
• NIST Special Publication 800-45 Version 2: Guide to Electronic Mail Security
• MITRE ATT&CK Framework: T1566 (Phishing) and T1189 (Drive-by Compromise)

Questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit di cybersicurezza professionale o un servizio di risposta agli incidenti.