Ataki CSS na webmail i narzędzia AI: nowe ryzyko przejęcia sesji oraz kradzieży tokenów

Wprowadzenie do problemu

Ataki CSS w środowiskach webmail pokazują, że nawet warstwa odpowiedzialna wyłącznie za prezentację treści może zostać wykorzystana do naruszenia bezpieczeństwa użytkownika. W praktyce oznacza to możliwość wpływania na interfejs klienta pocztowego, podszywania się pod legalne elementy formularzy, a nawet pośredniego wycieku danych uwierzytelniających i tokenów sesyjnych.

Problem nabiera dodatkowego znaczenia w chwili, gdy skrzynki pocztowe są integrowane z narzędziami AI. Złośliwie przygotowana wiadomość może bowiem oddziaływać nie tylko na człowieka, ale również na automatycznego asystenta analizującego treść poczty, tworzącego szkice odpowiedzi lub wykonującego operacje w imieniu użytkownika.

W skrócie

Najnowsze badania wskazują, że wybrane usługi webmail mogły być podatne na nadużycia związane z dozwolonym HTML i CSS oraz z rozbieżnościami między sanitizacją treści a jej finalnym renderowaniem w przeglądarce. Wśród analizowanych platform znalazły się m.in. Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail i AOL Mail.

Scenariusze ataku obejmują fałszowanie elementów interfejsu, przejmowanie tokenów poprzez interakcję użytkownika, omijanie części zabezpieczeń opartych na CSP oraz pośrednie prompt injection wymierzone w agentów AI korzystających z poczty elektronicznej.

Kontekst i historia

Przez lata bezpieczeństwo poczty elektronicznej skupiało się głównie na phishingu, złośliwych załącznikach, spoofingu nadawcy oraz aktywnych skryptach. CSS był zwykle uznawany za technologię niskiego ryzyka, ponieważ sam w sobie nie wykonuje logiki w sposób charakterystyczny dla JavaScript.

To podejście okazało się jednak zbyt optymistyczne. Jeśli nieufna wiadomość HTML zachowuje część stylów po przejściu przez mechanizmy filtrujące, a następnie jest renderowana blisko zaufanych elementów aplikacji, powstaje niebezpieczna granica zaufania. W efekcie atakujący może manipulować widokiem, ukrywać lub nadpisywać elementy interfejsu oraz tworzyć warunki do przejęcia konta bez uruchamiania klasycznego złośliwego kodu.

Analiza techniczna

Techniczny rdzeń tych ataków opiera się na dwóch zjawiskach. Pierwszym jest nadużycie oficjalnie dozwolonych funkcji CSS i HTML. Drugim są różnice pomiędzy tym, co sanitizer uznaje za bezpieczne, a tym, jak przeglądarka i skrypty aplikacji interpretują treść po osadzeniu jej w modelu DOM.

W jednym z opisywanych scenariuszy dozwolone elementy, takie jak etykiety formularzy, mogły oddziaływać na kontrolki znajdujące się poza właściwym obszarem wiadomości. Dodatkowo logika aplikacji mogła tworzyć nowe elementy DOM na podstawie atrybutów uznanych wcześniej za niegroźne. To prowadzi do powstania tak zwanego CSS gadget, czyli mechanizmu umożliwiającego obejście ograniczeń sanitizera i uzyskanie wpływu na pozycjonowanie lub wygląd krytycznych komponentów interfejsu.

Inny wariant dotyczył kopiowania i wklejania treści do szkicu wiadomości. Jeśli styl wklejanego HTML pozostaje aktywny choćby przez bardzo krótki moment przed pełną sanitizacją, możliwe staje się zbudowanie kanału bocznego służącego do odczytu tokenu logowania lub innego sekretu wykorzystywanego przez usługę.

Badania pokazały również, że odpowiednio skonstruowane selektory CSS mogą ujawniać informacje o strukturze dokumentu lub jego zawartości, nawet bez użycia JavaScript. W praktyce pozwala to testować obecność określonych znaków, cyfr czy fragmentów tekstu i stopniowo odzyskiwać cenne dane.

Szczególnie istotny jest wymiar związany z AI. Jeżeli klient pocztowy lub zintegrowany agent analizuje wiadomości, podsumowuje je albo wykonuje akcje na koncie, to spreparowany e-mail może zostać użyty jako nośnik instrukcji dla modelu. W takim scenariuszu atakujący nie musi bezpośrednio oszukiwać użytkownika. Wystarczy, że wpłynie na zachowanie asystenta działającego w zaufanym kontekście i skłoni go do przetworzenia, zapisania lub ujawnienia wrażliwych danych.

Konsekwencje i ryzyko

Ryzyko tej klasy ataków jest wysokie, ponieważ podważa podstawowe założenie, że treść wiadomości jest wyraźnie oddzielona od interfejsu aplikacji. Gdy użytkownik nie ma pewności, które elementy pochodzą od dostawcy usługi, a które zostały spreparowane przez nadawcę, skuteczność phishingu znacząco rośnie.

Drugim poważnym skutkiem jest możliwość przejęcia tokenów i sesji bez stosowania malware czy aktywnych skryptów. To oznacza, że tradycyjne założenia bezpieczeństwa, oparte na blokadzie JavaScript i restrykcyjnej polityce CSP, nie zawsze wystarczają.

W środowiskach korporacyjnych konsekwencje mogą obejmować:

przejęcie kont pocztowych,
nieautoryzowany dostęp do korespondencji,
obejście procesów MFA opartych na poczcie,
eskalację kampanii BEC,
nadużycie uprawnień agentów AI,
wyciek danych przetwarzanych przez asystentów pocztowych.

Z perspektywy SOC i zespołów blue team to szczególnie trudny problem, ponieważ atak nie musi generować klasycznych artefaktów kojarzonych ze złośliwym kodem wykonywalnym.

Rekomendacje

Najważniejszym krokiem dla dostawców usług webmail jest silna izolacja wiadomości HTML od reszty interfejsu aplikacji. Treść wiadomości nie powinna współdzielić kontekstu DOM z formularzami logowania, panelami ustawień, komponentami sesyjnymi ani przyciskami odpowiedzialnymi za operacje wrażliwe.

Niezbędne jest również zaostrzenie sanitizacji CSS. Zamiast szerokich list dozwolonych właściwości lepiej stosować model minimalnych uprawnień, z precyzyjną walidacją wartości, składni i dozwolonych mechanizmów renderowania. Szczególną uwagę należy zwrócić na selektory atrybutów, pseudoelementy, funkcje ładowania zasobów oraz wszystkie miejsca, w których dane wejściowe są później przekształcane przez logikę aplikacji.

Organizacje korzystające z webmaila i integracji AI powinny wdrożyć dodatkowe środki ochronne:

testy bezpieczeństwa wiadomości HTML i mechanizmów renderowania,
audyty pod kątem CSS gadgets oraz błędów sanitizacji,
monitorowanie anomalii w interfejsach pocztowych,
ograniczenie uprawnień agentów AI do tokenów, szkiców i działań wysokiego ryzyka,
wymóg jawnej autoryzacji użytkownika dla operacji wrażliwych,
szkolenia uświadamiające, że nawet pole logowania widoczne w skrzynce może być spreparowane.

W przypadku narzędzi AI kluczowe jest traktowanie każdej wiadomości jako danych nieufnych oraz odseparowanie analizy treści od wykonywania poleceń. Mechanizmy anty-prompt-injection powinny być standardem wszędzie tam, gdzie model ma możliwość działania na koncie użytkownika.

Podsumowanie

Ataki CSS na klientów webmail pokazują, że granica między treścią a zaufanym interfejsem może zostać naruszona bez użycia JavaScript. To istotna zmiana w modelu zagrożeń, ponieważ umożliwia kradzież tokenów, przejęcie sesji oraz skuteczniejsze podszywanie się pod elementy aplikacji w legalnym kontekście użytkownika.

Jeszcze poważniejsze są konsekwencje dla środowisk korzystających z AI. Gdy agent pocztowy uzyskuje dostęp do skrzynki, szkiców i funkcji automatyzacji, złośliwa wiadomość może stać się narzędziem wpływu na system działający z wysokim poziomem zaufania. Dla dostawców usług i organizacji oznacza to konieczność ponownego przemyślenia izolacji treści, sanitizacji CSS oraz zasad bezpieczeństwa dla asystentów AI.