Дослідник PortSwigger Гарет Гейз показав, що шкідливий лист може використати дозволений або недостатньо очищений CSS, щоб впливати на довірений інтерфейс webmail навколо повідомлення. Продемонстровані ланцюжки дають змогу відстежити відкриття листа, накрити частину сторінки контрольованим вмістом, перенаправити клік і створити фальшиву форму входу, яка перехоплює пароль без JavaScript.
Це не означає, що відкриття будь-якого листа автоматично краде пароль. Різні демонстрації стосувалися різних продуктів і браузерів, а деякі потребують кліку, вставлення тексту або введення даних у підроблене поле. Частину проблем виправили під час розкриття; за даними звіту, окремі можливості залишалися на момент публікації. Практичний висновок: формі входу всередині відкритого листа не можна довіряти лише тому, що адресний рядок браузера показує справжній домен поштового сервісу.
Як CSS виходить за межі листа
Webmail має відображати недовірений HTML усередині довіреної програми. Зазвичай сервіс видаляє скрипти й фільтрує CSS перед показом повідомлення. Нове дослідження зосереджене на розбіжностях між тим, що фільтр вважає безпечним, і тим, що браузер створює з цього коду пізніше.
HTML-мітки можуть активувати елементи інтерфейсу поза межами листа. CSS-селектори та згенерований вміст здатні накрити довірені кнопки або перенаправити клік. Браузер також може змінити екранований CSS після перевірки, через що правило впливатиме на більшу частину сторінки. Якщо зловмисник отримує контроль над макетом, він може намалювати поле пароля безпосередньо в поштовій скриньці й зробити його схожим на справжній вхід.
В одній демонстрації для Outlook CSS-компонент поєднали з поведінкою Firefox, щоб створити перехоплення пароля в реальному часі. У Fastmail CSS-мутація та «hotwiring» перетворювали клік на сторінці на іншу дію інтерфейсу. Звіт також описує обходи проксі зображень у кількох сервісах, але не стверджує, що існує один універсальний експлойт для всіх провайдерів.
Яка дія створює ризик?
| Що сталося | Ризик і що робити |
|---|---|
| Ви лише переглянули лист | Не панікуйте. На етапі перегляду можливі відстеження або зовнішній запит, але в показаних сценаріях викрадення пароля потрібна додаткова взаємодія. Закрийте лист, оновіть браузер або поштову програму й не вводьте дані в раптову форму входу. |
| Ви натиснули всередині дивного або візуально зламаного листа | CSS-накладка може спрямувати клік на іншу кнопку. Перевірте, чи не було лист закріплено, переміщено або відкрито нову сторінку. Не продовжуйте вхід через форму, що з’явилася всередині повідомлення. |
| Ви вставили токен або секрет у чернетку | Вважайте значення потенційно розкритим. Відкличте секрет або сесійний токен, якщо він має цінність, і перевірте чернетку, підключені програми та активність облікового запису. |
| Ви ввели пароль у форму всередині webmail | Вважайте пароль перехопленим. Відкрийте провайдера в новій вкладці або офіційній програмі, змініть пароль, завершіть інші сесії та перевірте пересилання, способи відновлення, MFA й доступ програм. |
Звичайна перевірка фішингу часто зосереджена на посиланнях, які виводять користувача з поштової скриньки. Варто й надалі перевіряти відправника та домен, як у випадку фішингових листів LastPass і Bitwarden, але це дослідження додає нове правило: форма облікових даних не стає безпечною лише тому, що вона з’явилася на справжньому домені webmail.
Як розпізнати CSS-пастку входу
- Форма входу з’являється одразу після відкриття або кліку в одному листі, а за нею видно інтерфейс поштової скриньки.
- Повідомлення каже, що сесія завершилася, але сервіс не перезавантажився й не перейшов на звичну сторінку автентифікації.
- Макет сторінки змінюється, лист накриває панель інструментів або клік по порожньому місцю виконує неочікувану дію.
- Форма поводиться інакше в іншому браузері, мобільній програмі провайдера або після повторного відкриття сервісу із закладки.
- Менеджер паролів не розпізнає поле як звичайну форму входу провайдера.
Якщо пошта раптово просить пароль, закрийте вкладку. Відкрийте нову, скористайтеся збереженою закладкою або офіційною програмою та перевірте стан облікового запису там. Справжній запит повторної автентифікації залишиться після незалежного переходу; форма, створена вмістом листа, — ні.
Що робити після введення пароля
- Скористайтеся незалежним шляхом. Відкрийте провайдера із закладки або офіційної програми. Не використовуйте кнопку чи форму з підозрілого листа.
- Змініть пароль. Якщо він повторювався в інших сервісах, замініть і ці копії на унікальні.
- Відкличте сесії та доступ програм. Завершіть інші сесії, видаліть невідомі OAuth-програми й перевірте входи, пристрої, локації та події безпеки.
- Перевірте закріплення в пошті. Перегляньте адреси пересилання, правила inbox, делегатів, резервну пошту й телефон, псевдоніми, паролі програм і нещодавно видалені листи.
- Посильте автентифікацію. Додайте стійку до фішингу MFA або ключ доступу, якщо сервіс підтримує. Спочатку видаліть невідомий метод.
- Повідомте організацію. Для робочого облікового запису зв’яжіться з IT або командою безпеки через інший довірений канал, щоб вони зберегли журнали й перевірили пов’язані акаунти.
Суміжний сценарій фішингу кодом пристрою Microsoft показує іншу пастку: справжня сторінка входу також не гарантує безпечної дії, якщо код або процес ініціював зловмисник. Адміністраторам Exchange Online варто окремо враховувати Ghost-Sender, де знайоме ім’я відправника не доводить справжність листа.
Що мають змінити розробники webmail
PortSwigger рекомендує суворо ізолювати вміст повідомлення, бажано в sandboxed iframe, щоб недовірений код не міг стилізувати довірену програму. Фільтр має блокувати зовнішні запити, небезпечні селектори й непотрібні інтерактивні елементи, а також повторно перевіряти CSS після перетворення браузерним парсером. Окремо потрібно шукати «gadgets» — компоненти, які беруть дозволений атрибут із листа й додають потужніші стилі до сторінки.
Для організацій оновлення необхідне, але одного gateway недостатньо. Поштовий шлюз може видалити активний вміст, однак фінальна межа безпеки належить webmail-рендереру. Тести мають охоплювати шкідливий HTML/CSS без скриптів, різні браузери, проксі зображень і всі бібліотеки, які працюють з очищеним повідомленням.
FAQ
Чи може просте відкриття листа викрасти пароль через CSS?
Звіт описує відстеження на етапі перегляду, але для демонстрацій перехоплення пароля користувач має взаємодіяти з підробленим елементом — наприклад, натиснути або ввести дані. Умови залежать від продукту, браузера й виправлень, тому саме відкриття не є доказом крадіжки пароля.
Чи зупинить атаку блокування JavaScript?
Не повністю. Дослідження показує, що HTML і CSS можуть впливати на інтерфейс і створювати пастку для пароля без JavaScript. Видалення скриптів важливе, але webmail також має ізолювати й суворо фільтрувати стилі та елементи.
Чи треба змінювати пароль після одного перегляду листа?
Зазвичай ні, якщо немає інших ознак. Змініть його, якщо вводили у неочікувану форму, підтвердили невідомий вхід, побачили сторонню сесію або маєте інший надійний індикатор доступу. Після лише перегляду закрийте лист, оновіть клієнт і стежте за активністю.
Джерела
- Heyes, Gareth. «CSS: The Bomb Inside Your Inbox». PortSwigger Research, опубліковано 6 серпня 2026 року; дата звернення: 8 серпня 2026 року. технічний звіт.
- PortSwigger. «css-the-bomb-inside-your-inbox». GitHub, супровідні матеріали до дослідження Black Hat USA 2026; дата звернення: 8 серпня 2026 року. офіційні матеріали.
