Как веб-пуш уведомления превращаются в скрытые векторы атак

Скрытая угроза, о которой никто не говорит

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

Речь о уязвимости Sleeping Agent — атаке, которая использует слабое место в проверке безопасности Web Push API браузерами.

Где кроется опасность

Web Push API содержит важное требование — userVisibleOnly: true. Оно означает, что каждое push-сообщение должно сопровождаться видимым уведомлением. Это своего рода договорённость между сайтом и браузером.

На практике всё работает иначе.

Злоумышленник регистрирует вредоносный Service Worker, который при получении push-события сразу выполняет два действия:

1. Вызывает showNotification() и показывает уведомление.
2. Немедленно закрывает его через notification.close().

Уведомление успевает попасть в базу данных браузера, но исчезает с экрана до того, как пользователь его заметит. При проверке браузер смотрит не на то, что отображается на экране, а на записи в базе. В результате проверка проходит успешно, а пользователь ничего не видит. Канал управления остаётся активным и незаметным.

Почему это важно

Такая атака затрагивает сразу несколько аспектов безопасности:

• Скрытое постоянство. Злоумышленник получает долгосрочный канал связи без установки malware. Достаточно одного визита на заражённый сайт.
• Обход ограничений. Многие стандарты безопасности опираются на видимые уведомления как на границу доверия. Эта атака наруяет эту границу.
• Широкий охват. Уязвимость работает в Chrome, Edge и даже в старых версиях Safari.
• Простота реализации. Для проведения атаки не требуется сложный инструментарий — она воспроизводима на стабильных версиях браузеров в течение пяти минут.

Как работает атака

Проблема в том, что проверка безопасности происходит уже после того, что выполнил Service Worker. Вот как это выглядит:

1. Приходит push-событие.
2. Service Worker показывает уведомление и сразу его закрывает.
3. Работа Service Worker заканчивается.
4. Браузер проверяет наличие записи в базе данных.
5. Запись есть — проверка проходит.
6. Событие считается валидным.

Timing window здесь небольшой, но вполне достаточный для надёжной эксплуатации.

Что делать разработчикам

Если вы используем Web Push в своих приложениях, стоит подумать над несколькими вопросами:

• Проверяете ли вы Service Worker на подозрительное поведение в части уведомлений? Если третья сторона получит доступ к вашему Service Worker, вся ответственность за атаку ложится на вас.
• Ведёте ли вы логирование вызовов showNotification() и close()? Это поможет обнаружить странные паттерны.
• Проверяете ли источник push-сообщений? Внедрите криптографическую верификацию, чтобы гаранти<|eos|>