Wprowadzenie do problemu / definicja
Nowe badania pokazują, że treść wiadomości e-mail renderowana w interfejsie webmaila może oddziaływać na zaufane elementy aplikacji, jeśli mechanizmy izolacji i sanitizacji nie są wystarczająco restrykcyjne. W praktyce oznacza to, że odpowiednio przygotowany HTML i CSS osadzony w wiadomości może wpływać na wygląd i zachowanie interfejsu pocztowego, otwierając drogę do kradzieży danych uwierzytelniających, wycieku tokenów oraz manipulowania działaniami użytkownika.
To istotna zmiana w postrzeganiu zagrożeń związanych z pocztą webową. Przez lata główny nacisk kładziono na blokowanie JavaScriptu i aktywnego kodu, tymczasem najnowsze demonstracje pokazują, że również sam CSS może stać się skutecznym narzędziem ataku.
W skrócie
- Badacze zaprezentowali nowe łańcuchy ataków wykorzystujące HTML i CSS w popularnych usługach webmail.
- W scenariuszach proof-of-concept pojawiły się m.in. Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail oraz AOL Mail.
- Opisane techniki obejmują przechwytywanie haseł, wyciek tokenów, click hijacking oraz nadużycia na styku poczty i narzędzi AI.
- Nie przedstawiono dowodów na aktywne wykorzystanie tych metod w realnych kampaniach, ale ryzyko architektoniczne jest istotne.
Kontekst / historia
Problem nie sprowadza się do pojedynczej klasycznej podatności, lecz do szerszej kategorii słabości architektonicznych w sposobie, w jaki webmaile renderują wiadomości HTML. Dostawcy poczty od lat próbują znaleźć równowagę między bezpieczeństwem a wygodą użytkownika, dopuszczając część znaczników i stylów potrzebnych do zachowania bogatego formatowania wiadomości.
Badania pokazują jednak, że nawet jeśli treść wiadomości przejdzie przez filtr bezpieczeństwa, nadal może dojść do rozbieżności między tym, co zostało zaakceptowane przez mechanizm sanitizacji, a tym, co ostatecznie interpretuje przeglądarka lub kod aplikacji. Tego rodzaju różnice mogą powodować, że nieufna treść zaczyna wpływać na zaufany interfejs otaczający wiadomość.
W efekcie problem obejmuje zarówno nadużycia wynikające z wykorzystania dozwolonych funkcji HTML i CSS w nieprzewidziany sposób, jak i mutacje dokumentu zachodzące już po sanitizacji. To właśnie te scenariusze tworzą przestrzeń do przejmowania akcji użytkownika i wycieku wrażliwych danych.
Analiza techniczna
Opisane łańcuchy ataków wykorzystują fakt, że webmail musi dopuścić przynajmniej część HTML i CSS, aby wiadomości zachowały poprawne formatowanie. Jeśli jednak wiadomość nie jest odpowiednio odizolowana od głównego interfejsu aplikacji, atakujący może użyć dozwolonych selektorów, etykiet, pseudoelementów lub zapytań medialnych do wpływania na elementy UI znajdujące się poza samą treścią e-maila.
W jednym z przykładów dotyczącym Outlooka badacz wykazał, że dozwolone elementy typu label mogą aktywować kontrolki znajdujące się poza obszarem wiadomości. Dodatkowo pewne transformacje wykonywane przez aplikację po sanitizacji miały prowadzić do utworzenia nowych elementów DOM zawierających CSS wykraczający poza pierwotne ograniczenia. Po połączeniu tego z odpowiednim parsowaniem media queries możliwe było uzyskanie szerokiego wpływu na stylowanie interfejsu.
Kolejny etap demonstracji polegał na wizualnym zamaskowaniu pola select tak, aby przypominało pole hasła. W przeglądarce Firefox zachowanie związane z resetowaniem wyboru po przesunięciu elementu poza ekran miało umożliwiać quasi-rzeczywiste przechwytywanie wpisywanych znaków. Taki scenariusz pokazuje, że granica między zwykłą manipulacją wizualną a faktycznym pozyskaniem sekretów może być bardzo cienka.
W przypadku Yahoo Mail i AOL Mail opisano z kolei warunek wyścigu związany z wklejaniem HTML w Firefoxie. Przez krótki moment po wklejeniu złośliwa zawartość miała zachowywać aktywny CSS jeszcze przed pełną sanitizacją. W zaprezentowanym scenariuszu wystarczało, aby ofiara skopiowała przygotowany ładunek i wkleiła go do szkicu wiadomości, a seria żądań sieciowych ujawniała część tokenu logowania, którą następnie można było odtworzyć po stronie atakującego.
Badanie opisuje także technikę eksfiltracji opartą na kliknięciu, przydatną w środowiskach chronionych przez politykę CSP blokującą zewnętrzne zasoby. Jeśli napastnik jest w stanie wstrzyknąć style, a poufny token zostaje wyrenderowany jako tekst liczbowy, CSS może pomóc ustalić, które cyfry występują i z jaką częstotliwością. Następnie odpowiednio przygotowany interfejs może skierować kliknięcie użytkownika do jedynego widocznego odnośnika, który przekaże dane do infrastruktury atakującego.
Szczególnie ważny jest także wątek integracji z narzędziami AI. Jeden z łańcuchów związanych z Gmailem miał wykorzystywać zachowanie image-set() do wykonania zewnętrznego żądania mimo filtracji. Po połączeniu tej techniki z pośrednim prompt injection w wiadomości analizowanej przez asystenta AI możliwe było doprowadzenie do sytuacji, w której agent odnalazł token z powiązanej usługi, umieścił go w szkicu HTML, a następnie ujawnił podczas podglądu. To pokazuje, że współczesny model zagrożeń obejmuje już nie tylko sam webmail, ale również systemy AI pracujące na skrzynce użytkownika.
W badaniu wspomniano również o dodatkowych wektorach, takich jak CSS hotwiring w Fastmail, obejścia proxy obrazów oraz warianty naruszające prywatność użytkownika przez ujawnienie adresu IP lub momentu otwarcia wiadomości.
Konsekwencje / ryzyko
Ryzyko biznesowe jest znaczące, ponieważ webmail pozostaje jednym z najważniejszych interfejsów pracy użytkownika i często pełni rolę centrum tożsamości cyfrowej. Skuteczny atak może prowadzić do przejęcia hasła, sesji, tokenów logowania, kodów jednorazowych lub innych sekretów związanych z usługami SaaS.
Z punktu widzenia obrony szczególnie niebezpieczne jest to, że opisane techniki nie wymagają klasycznego malware ani uruchamiania JavaScriptu. W wielu organizacjach CSS bywa traktowany jako relatywnie bezpieczny, tymczasem połączenie stylów, niuansów renderowania, logiki aplikacyjnej i interakcji użytkownika może dać napastnikowi realne możliwości eksfiltracji i manipulacji interfejsem.
Dodatkowym mnożnikiem ryzyka jest automatyzacja oparta na AI. Jeżeli agent ma dostęp do wiadomości, szkiców i połączonych usług, to każda słabość na styku renderowania treści i automatycznego przetwarzania danych może prowadzić do niezamierzonego ujawnienia informacji bez potrzeby dostarczania tradycyjnego złośliwego oprogramowania.
Rekomendacje
Dostawcy webmaili powinni traktować wiadomości HTML jako treść o zerowym zaufaniu i renderować je w ściśle odizolowanym środowisku, najlepiej z użyciem sandboxowanych ramek iframe oraz rygorystycznych ograniczeń dotyczących możliwości interakcji z głównym DOM aplikacji.
Obsługa CSS powinna zostać ograniczona do minimalnego, jawnie zdefiniowanego podzbioru. W praktyce oznacza to ścisłą walidację właściwości, wartości i selektorów oraz ostrożne podejście do takich mechanizmów jak image-set(), pseudoelementy, media queries, niestandardowe atrybuty czy wszystko, co może skutkować pośrednim wykonaniem żądań sieciowych.
Niezbędne jest także badanie końcowego stanu dokumentu po pełnym renderowaniu, a nie tylko samego wyniku sanitizacji. Każda mutacja DOM wykonywana przez aplikację po zaakceptowaniu treści może odtworzyć niebezpieczny stan i umożliwić obejście wcześniejszych zabezpieczeń.
Organizacje korzystające z webmaili i integracji AI powinny przeprowadzić przegląd konfiguracji bezpieczeństwa, ograniczyć uprawnienia agentów AI do połączonych usług oraz monitorować anomalie w ruchu wychodzącym, otwieraniu szkiców i procesach logowania. Warto również szkolić użytkowników, aby unikali kopiowania i wklejania nietypowej treści do draftów oraz zachowali ostrożność wobec próśb o ponowne logowanie z poziomu wiadomości.
- Izolować wiadomości HTML od głównego interfejsu webmaila.
- Ograniczać obsługę CSS do niezbędnego minimum.
- Testować końcowy DOM po wszystkich transformacjach aplikacyjnych.
- Kontrolować integracje AI i minimalizować ich uprawnienia.
- Stosować MFA odporne na phishing tam, gdzie to możliwe.
Podsumowanie
Nowe techniki ataków CSS na webmaile pokazują, że bezpieczeństwo renderowania wiadomości HTML nadal pozostaje problemem systemowym. Sednem zagrożenia nie jest pojedynczy błąd, lecz złożona interakcja między sanitizacją, przeglądarką, logiką aplikacji i narzędziami AI. W efekcie nawet pozornie pasywna wiadomość e-mail może stać się narzędziem przechwytywania haseł, wycieku tokenów i manipulowania zaufanym interfejsem użytkownika.
Dla dostawców poczty oznacza to konieczność głębszej izolacji treści i bardziej rygorystycznego podejścia do HTML oraz CSS. Dla organizacji i zespołów bezpieczeństwa to sygnał, że modele zagrożeń muszą dziś obejmować nie tylko sam webmail, ale również agentów AI operujących na danych ze skrzynek pocztowych.
Źródła
- New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens — https://thehackernews.com/2026/08/new-css-attacks-can-break-webmail.html
- PortSwigger Research — New CSS attacks impact Gmail, Fastmail, Outlook, Proton Mail, Yahoo and AOL — https://portswigger.net/research/new-css-attacks-impact-gmail-fastmail-outlook-proton-mail-yahoo-and-aol
- Black Hat USA 2026 Briefings — https://www.blackhat.com/us-26/briefings/schedule/index.html
- Proton Mail tracker protection documentation — https://proton.me/support/email-tracker-protection
- Claude support documentation for Gmail connector — https://support.claude.com/