CSS-инъекции против почты и AI-читалок: как письмо может украсть токены через интерфейс

Дата
CSS-инъекции против почты и AI-читалок: как письмо может украсть токены через интерфейс

Письмо становится риском не только из-за ссылки или вложения. Если почтовый интерфейс и AI-читалка обрабатывают активную разметку небезопасно, само отображение сообщения может повлиять на границы интерфейса и утечки токенов.

Главный риск — считать тело письма обычным текстом. Вредоносные стили могут заставить интерфейс загрузить внешние ресурсы, обойти защиту почтового клиента или дать AI-читалке небезопасный слой данных для анализа.

Как это выглядит в атаке или ошибке

В атаке письмо содержит разметку и стили, которые меняют поведение отображения. Почтовая система показывает сообщение, браузер загружает ресурсы или меняет видимость элементов, а AI-читалка может получить опасный контент как часть входных данных.

  • подготовить письмо с вредоносными стилями;
  • добиться открытия в веб-почте;
  • вызвать загрузку внешнего ресурса;
  • изменить видимость или слой интерфейса;
  • передать опасный контент AI-читалке;
  • связать событие с попыткой кражи токена или пароля.

Какие следы искать

  • необычные внешние запросы при открытии письма;
  • опасные стили внутри сообщения;
  • аномалии отображения почтового интерфейса;
  • расхождение между безопасным текстом и разметкой;
  • обращения к доменам сразу после просмотра;
  • события токенов рядом с открытием письма.

Защитные действия

  • очищать стили и активную разметку;
  • изолировать отображение письма от интерфейса;
  • включить строгую политику загрузки ресурсов;
  • передавать AI только очищенный текст;
  • журналировать внешние загрузки из почты;
  • проверять письма с необычной разметкой в песочнице.

Практический кейс

Кейс: пользователь открывает письмо без вложений, после чего прокси фиксирует запрос к внешнему домену. Проверка показывает, что запрос вызван стилем внутри сообщения. Команда отключает опасную разметку, проверяет токены и добавляет правило для похожих писем.

CSS-инъекции против почты и AI-читалок: как письмо может украсть токены через интерфейс

Минимальный набор проверок

  • сравнить сырой код письма и безопасный текст;
  • проверить внешние загрузки ресурсов;
  • настроить изоляцию отображения;
  • передавать AI-читалке только очищенный вариант;
  • добавить журнал событий открытия письма;
  • проверить, что токены не доступны из контекста письма.

Техническая настройка

Сценарий нужно запускать как контролируемый защитный процесс. До включения AI определяются источники данных, права, границы автоматизации и условия ручного подтверждения.

  • назначить владельца сценария и владельца риска;
  • описать разрешённые источники данных;
  • включить маскирование секретов и персональных данных;
  • запретить автоматические изменения без подтверждения;
  • вести журнал запросов, ответов и решений;
  • проверять качество на контрольной выборке.

Поля для SIEM

  • время события и источник;
  • учётная запись, роль или сервис;
  • тип действия: чтение, запуск, изменение, загрузка или вход;
  • объект действия: файл, письмо, устройство, приложение или данные;
  • признаки риска и причина повышения приоритета;
  • решение аналитика и итог проверки.

Если AI используется для обогащения карточки, он должен ссылаться на конкретные события. Неподтверждённые предположения нужно явно отделять от фактов.

Пример правила корреляции

Правило должно собирать слабые признаки в цепочку. Один сигнал остаётся наблюдением, а несколько связанных сигналов становятся поводом для проверки.

  • первый признак: новое действие или новый источник;
  • второй признак: короткий интервал между событиями;
  • третий признак: доступ к чувствительному объекту;
  • четвёртый признак: нетипичная роль или устройство;
  • пятый признак: повтор похожих попыток;
  • итог: повышение приоритета и передача аналитику.

Безопасное подключение AI

AI не должен получать полный поток данных без подготовки. Сначала события нужно нормализовать, убрать секреты и оставить только контекст, нужный для конкретной карточки.

  • передавать только нужное окно времени;
  • заменять секреты и токены на маркеры;
  • указывать источник каждого события;
  • запрещать вывод без ссылки на факт;
  • сохранять запрос и ответ в карточке инцидента;
  • не давать AI права менять настройки или доступы.

Рабочая процедура

Процедура должна быть понятна дежурному аналитику. Если правило сработало ночью, человек должен увидеть краткую цепочку, список доказательств и безопасный следующий шаг.

  • открыть карточку с полной цепочкой событий;
  • проверить самые ранние действия;
  • сравнить поведение с обычным профилем владельца;
  • посмотреть связанные сетевые и файловые события;
  • принять решение об изоляции или наблюдении;
  • записать причину решения в журнал.

Проверка качества

  • сравнить вывод AI с ручной проверкой;
  • проверить ложные срабатывания на штатных событиях;
  • добавить отрицательные примеры;
  • проверить маскирование чувствительных данных;
  • запретить автоматическое изменение прав и настроек;
  • обновлять правила после каждого разбора.

Критерии готовности

Сценарий можно расширять только после проверки качества. Команда должна видеть, что правило ловит нужные цепочки, AI не придумывает факты, а аналитик может повторить вывод вручную.

  • есть набор контрольных событий;
  • есть описание ложных срабатываний;
  • понятно, какие поля обязательны;
  • есть порядок отключения AI-обогащения;
  • есть владелец правила и срок пересмотра;
  • есть отчёт о пользе после пилота.

Как не расширить риск

При внедрении важно не превращать защитный помощник в новый источник неконтролируемых действий. Любая интеграция должна работать по принципу минимального контекста и проверяемого результата.

  • не передавать в модель полные журналы без необходимости;
  • не хранить секреты в подсказках и описаниях задач;
  • не разрешать вызовы внешних систем без отдельного правила;
  • не скрывать от аналитика источники вывода;
  • не включать автоматическую блокировку на первом этапе;
  • не считать красивое резюме доказательством.

Разбор после пилота

Через две недели пилота нужно оценить не только скорость, но и качество решений. Если AI ускорил разбор, но добавил неподтверждённые выводы, сценарий нужно сузить и добавить новые ограничения.

  • сколько карточек разобрано быстрее;
  • сколько выводов подтвердилось;
  • какие поля журнала чаще всего отсутствовали;
  • какие правила дали шум;
  • какие действия нельзя автоматизировать;
  • какие контрольные примеры добавить.

Почтовая безопасность для AI-читалок начинается до модели. Если небезопасная разметка попадает в отображение и в AI-контекст, письмо становится активным каналом воздействия, даже когда в нём нет вложения.

Ещё по теме