Один из наглядных примеров — авторизационный side-channel через редиректы и статические ресурсы (favicon, изображения и т.п.).
🧠 СУТЬ МЕХАНИЗМА
При попытке загрузить ресурс вроде https://service.com/favicon.ico с редиректом на страницу логина сайт-инициатор получает бинарный сигнал:
сессия активна → происходит редирект и успешная загрузка ресурса (срабатывает onload);
сессии нет → редиректа нет, запрос падает с ошибкой (onerror).
В результате внешний сайт, не имея доступа ни к кукам, ни к API, может определить факт авторизации пользователя на стороннем домене.
Фактически это форма пассивного фингерпринтинга, использующего сетевое поведение и логику аутентификации.
🌟 ПОЧЕМУ ЭТО ПЛОХО? ТАКОЙ КАНАЛ ПОЗВОЛЯЕТ:
🟣 деанонимизировать пользователей между сервисами;
🟣 выявлять используемые экосистемы (Google, VK, Facebook и др.);
🟣 строить поведенческие профили без cookie-трекинга;
🟣 использовать сигналы авторизации для атак второго порядка (например, фишинг с контекстом активной сессии).
Даже при активных CORS-ограничениях подобные сценарии всё ещё возможны — особенно при цепочках редиректов и открытых статических ресурсах.
🔹 МИТИГИРУЮЩИЕ МЕРЫ
Для разработчиков и DevSec-команд:
🟣избегать «мягких» редиректов при проверке авторизации, возвращать чёткие статусы 401/403;
🟣ограничивать доступ к статическим ресурсам, которые могут использоваться как индикаторы авторизации;
🟣включить строгие политики реферера и CORS;
🟣проводить аудит публичных эндпоинтов на предмет side-channel утечек (в том числе favicon-based).
Для безопасников и аналитиков:
🟣отслеживать подобные паттерны в трафике, особенно при внешних интеграциях;
🟣включать проверки на подобные утечки в web-security-тестирование;
🟣учитывать авторизационные side-channels в моделях угроз.
⚠️ ЭТИЧЕСКИЙ АСПЕКТ
Метод описан исключительно в образовательных целях. Использование подобных техник для отслеживания пользователей без их согласия нарушает GDPR, ePrivacy и локальные регламенты по защите данных.