Emailul care repictează aplicația din jurul lui: atacuri CSS care sparg apărarea webmailului

Pe 6 august 2026, la Black Hat USA, cercetătorul Gareth Heyes de la PortSwigger a prezentat o serie de atacuri care pornesc de la o idee simplă și incomodă: conținutul dintr-un email poate ieși din chenarul mesajului și poate interveni în interfața clientului de webmail. Nu prin JavaScript, care este blocat de mult, ci prin HTML și CSS pe care furnizorii le permit deja.

Cum funcționează, la nivel de principiu

Un client de webmail trebuie să afișeze HTML scris de străini, în aceeași pagină cu propria interfață. Ca să facă asta în siguranță, curăță conținutul primit — elimină ce e periculos și păstrează ce e necesar pentru ca mesajele să arate normal. Atacurile prezentate lovesc exact în acest compromis, pe două căi.

• Abuzează elemente HTML și CSS pe care furnizorul le permite oricum. Un exemplu concret: elementele „label" permise în Outlook pot activa controale aflate în afara mesajului, adică în interfața aplicației.
• Exploatează diferența dintre ce aprobă mecanismul de curățare și ce randează efectiv browserul. Sanitizatorul citește textul într-un fel, browserul îl interpretează altfel, iar între cele două interpretări încape atacul.

A doua cale ar trebui să sune cunoscut dacă ai citit articolul despre XSS2Shell din WordPress, publicat săptămâna trecută: acolo cauza era exact aceeași, două funcții de sanitizare care nu erau de acord ce înseamnă un tag. Se numește „parser differential" și este una dintre cele mai productive clase de vulnerabilități din ultimii ani, tocmai pentru că niciuna dintre componente nu greșește singură.

Ce s-a demonstrat concret

Au fost testate Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail și AOL Mail. Dintre lanțurile demonstrate:

• Outlook pe Firefox — falsificarea ecranului de autentificare Microsoft, cu captarea parolei în timp real.
• Yahoo și AOL — o tehnică bazată pe cursa dintre lipire și randare, prin care au fost expuse tokenuri de autentificare de la un serviciu terț.
• Gmail, în combinație cu un asistent AI conectat la inbox — exfiltrarea unor tokenuri Slack prin injecție de prompt, declanșată atunci când utilizatorul cere asistentului să proceseze mesajul.

Ultimul merită subliniat separat. Pe măsură ce tot mai multe organizații conectează asistenți AI la cutia poștală, emailul devine nu doar ceva ce citește un om, ci și ceva ce citește un sistem automat cu acces la unelte. Conținutul ostil dintr-un mesaj ajunge astfel instrucțiune pentru un agent care are permisiuni reale.

De ce nu ajută apărările obișnuite

Curățarea HTML și politicile de securitate a conținutului sunt necesare, dar aici se dovedesc insuficiente. Elementele permise pot declanșa controale din afara mesajului. Trucurile de parsare a CSS-ului pot ajunge la injectare arbitrară de stil. Se pot exploata detalii de temporizare din browser. Iar atributele personalizate pot crea noduri noi în structura paginii, care scapă de validare.

La momentul publicării, Fastmail reparase două probleme de mutație CSS, iar ocolirea prin proxy la Proton Mail nu mai funcționa. Tehnica de deturnare a etichetelor în Outlook și o ocolire prin funcția „image-set()" în Gmail erau încă active. Cercetarea nu precizează dacă lanțul complet de captare a parolei în Outlook a fost remediat.

Ce poți face tu și ce nu

Onest: cea mai mare parte a soluției nu îți aparține. Recomandările cercetării se adresează furnizorilor — izolarea emailului HTML în cadre separate, restricționarea strictă a CSS-ului prin liste de caractere permise, blocarea selectorilor periculoși și a meniurilor de selecție, împiedicarea cererilor de imagini controlate de atacator.

Ce rămâne în controlul unei organizații și al unui utilizator este însă suficient cât să conteze:

• Nu introduce niciodată o parolă într-un formular care a apărut în timp ce citeai un email. Dacă ți se cere să te autentifici, închide mesajul, deschide aplicația separat și autentifică-te acolo.
• Preferă passkey-urile. Fiind legate criptografic de domeniu, nu pot fi predate unui formular fals, oricât de bine arată el.
• Dacă ai conectat un asistent AI la inbox, tratează-l ca pe un utilizator cu permisiuni, nu ca pe o unealtă. Limitează ce poate atinge și presupune că orice email pe care îl citește poate încerca să îi dea instrucțiuni.
• Ține clientul de mail și browserul actualizate. O parte din lanțuri depind de comportamente specifice de browser, care se repară în timp.

Lecția pentru programele de awareness

Este a treia oară în două săptămâni când scriem despre un atac în care sfatul clasic „verifică adresa din bara de navigare" nu ajută cu nimic. La phishingul prin cod de dispozitiv, adresa era a Microsoft. La campania derulată prin Wi-Fi-ul hotelurilor, redirecționarea făcea parte din funcționarea normală a rețelei. Acum, ecranul fals apare chiar în interiorul aplicației corecte, pe domeniul corect.

Reflexul care rezistă la toate trei nu are legătură cu adresa, ci cu direcția acțiunii: cererea de autentificare a venit către tine sau ai pornit-o tu? Dacă un mesaj, o pagină sau un apel îți cere să te autentifici, singurul răspuns sigur este să deschizi tu aplicația, pe drumul pe care îl folosești de obicei. Este o regulă mai greu de predat decât „uită-te la lacăt", dar este singura care încă funcționează.