Уязвимости CSS в веб-почте: почему SPF и DMARC не защищают от атак на интерфейс

В материалах также рассматривается риск для AI-инструментов, которые читают содержимое входящих сообщений и взаимодействуют с веб-интерфейсом. Проблема находится не в SPF, DKIM или DMARC: эти механизмы проверяют происхождение и целостность сообщения, но не контролируют поведение HTML/CSS после его рендеринга в браузере.

Граница доверия ломается внутри веб-почты

Веб-почтовые клиенты разрешают часть HTML и CSS, чтобы отображать форматированные письма. Для ограничения риска применяется sanitizer с allow list — перечнем допустимых тегов, атрибутов и CSS-свойств. Базовое предположение выглядит так: стили влияют только на содержимое письма и не могут управлять доверенным интерфейсом вокруг него.

Исследование Хейеса ставит это предположение под сомнение. В описанных цепочках используются либо разрешённые CSS-возможности, либо расхождение между тем, что sanitizer считает безопасным, и тем, что фактически обрабатывает браузер. В результате недоверенный контент получает возможность взаимодействовать с элементами интерфейса, расположенными за пределами сообщения.

Затронутыми в исследовании названы Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail и AOL Mail. Отдельно упоминаются OpenAI Atlas и Firefox. Это перечень исследованных целей, а не утверждение о наличии одинаковой уязвимости во всех перечисленных системах.

Две показательные цепочки

Наиболее детально описан сценарий для Outlook. Разрешённые элементы label могут инициировать управление компонентами, находящимися вне письма. Дополнительный риск создаёт JavaScript самого Outlook: библиотека может добавить в DOM элемент со свойством или значением CSS, которое изначально отсутствовало в allow list sanitizer.

В отчёте такой механизм назван CSS gadget. Упоминается свойство position: fixed, позволяющее разместить элемент в произвольной точке страницы. Это нарушает границу между окном сообщения и остальным интерфейсом. Исследователь описал подмену выпадающего списка полем ввода пароля. В Firefox перемещение такого элемента за пределы видимой области сбрасывает примерно односекундный таймер выбора, что, согласно описанию атаки, позволяет получать ввод почти в реальном времени.

Другой сценарий относится к Yahoo Mail и AOL Mail и использует копирование HTML в черновик. В Firefox вставленный HTML некоторое время может сохранять активные стили до завершения очистки. В описанной цепочке через такую особенность извлекался 12-символьный токен входа по ссылке из письма. Пользователю требовалось вставить содержимое в черновик; после этого токен мог быть передан на сервер атакующего и использован для входа.

Описанные техники не сводятся к классическому фишинговому письму с поддельной ссылкой. Здесь атакующая логика размещается в представлении сообщения и зависит от взаимодействия webmail, sanitizer, DOM и браузера. Для AI-почты это отдельная зона контроля: инструмент может анализировать письмо как данные, но одновременно работать в том же доверенном интерфейсе, где выполняется вредоносная CSS-логика. Практические риски безопасности AI в цифровых сервисах дополнительно рассматриваются в методических рекомендациях Банка России по безопасности ИИ на финрынке.

Что проверить в почтовой инфраструктуре

Проверьте границу обработки HTML/CSS в используемом webmail. Наличие sanitizer не является достаточным подтверждением безопасности. Требуется установить:

• какие HTML-теги, атрибуты и CSS-свойства проходят allow list;
• может ли JavaScript интерфейса добавлять в DOM новые элементы с неподконтрольными sanitizer свойствами;
• допускается ли позиционирование элементов относительно всей страницы, а не только контейнера письма;
• сохраняются ли активные стили при вставке HTML в черновик;
• какие данные доступны CSS или связанным с ним механизмам при копировании и вставке;
• может ли содержимое сообщения воздействовать на элементы интерфейса за пределами окна письма.

Отдельно запретите передачу токенов через буфер обмена в пользовательских сценариях входа по email. Не рассматривайте короткий токен как безопасный только потому, что он не является паролем: в описанной цепочке именно получение токена давало возможность продолжить аутентификацию.

Для команд, разрабатывающих webmail и AI-агентов, порядок действий жёсткий. Изолируйте DOM письма от доверенного интерфейса. Минимизируйте разрешённый CSS. Проверяйте не только исходный HTML, но и итоговый DOM после работы JavaScript. Тестируйте рендеринг в Firefox и других поддерживаемых браузерах отдельно. Моделируйте сценарии с Outlook, Yahoo Mail, AOL Mail и остальными клиентами, перечисленными в исследовании.

SPF, DKIM и DMARC продолжайте настраивать для защиты домена и маршрутизации. Но не приписывайте им контроль над клиентским рендерингом. Эта задача относится к webmail, браузеру, sanitizer и изоляции интерфейса.