Межсайтовые утечки

Веб-приложения состоят из двух основных компонентов: браузера пользователя и одного или более веб-серверов. Как правило, коммуникация между ними осуществляется по протоколу HTTP и через соединения WebSocket для интерактивных функций. Для предоставления интерактивности браузер отображает HTML и CSS, исполняет JavaScript, загружаемый от сайта^[1]. Пользователь может взаимодействовать с веб-приложением долгое время, выполняя множественные запросы к серверу. Для отслеживания состояния обычно используется уникальный идентификатор, связанный с пользователем, его сессией или учётной записью^[2]. Такой идентификатор способен содержать дополнительные сведения — возраст, уровень доступа и т. п. Если эти атрибуты станут доступны посторонним сайтам, они могут привести к deanonymization.

Идеальная модель предполагает полную независимость веб-приложений друг от друга. Однако исторические решения в развитии веб-технологий привели к тому, что между приложениями возможны перекрёстные взаимодействия. Для предотвращения злоупотреблений внедрена политика одного источника, ограничивающая прямые межсайтовые обращения. Тем не менее веб-приложения требуют загрузки контента извне (скриптов, стилей, видео, изображений), что приводит к cross-origin-запросам — они регулируются специальным механизмом CORS (Cross-Origin Resource Sharing), требующим явного разрешения для доступа к данным других сайтов^[3].

Межсайтовые утечки позволяют атакующим обойти защиту same-origin и CORS. Они эксплуатируют так называемые побочные каналы (side channels), через которые становится возможным косвенно узнать защищённые данные — например, по длительности запроса, состоянию кэша и пр. В результате злоумышленник может узнать о предыдущем опыте пользователя с тем или иным веб-приложением.

Для атаки межсайтовой утечкой злоумышленник сначала изучает логику взаимодействия пользователя с целевым сайтом. Например, при атаке на Gmail он может найти специальную поисковую URL, возвращающую разные HTTP-ответы в зависимости от наличия определённых писем. После обнаружения такой URL атакующий размещает у себя вредоносный сайт и привлекает жертв, чтобы инициировать межсайтовый HTTP-запрос. Однако политика одного источника не позволит ему напрямую прочитать ни тело, ни метаданные ответа.

Для обхода этого ограничения применяются специальные приёмы: фрагменты JavaScript, CSS, HTML, позволяющие по косвенным признакам (время ожидания, изменение размера, ошибки загрузки) судить о содержимом ответа. К примеру, измеряя время получения ресурса, можно выяснить, были ли результаты поиска в письмах Gmail: быстрый возврат — нет результатов; долгий — речь идёт о множественных совпадениях. Повторяя запросы с разными параметрами, атакующий постепенно выстраивает портрет состояния учётной записи пользователя.

Межсайтовые утечки как проблема известны с 2000 года: уже тогда в исследовании Университета Пердью был теоретически описан атака на приватность через кэш браузера. В 2007 году Эндрю Борц и Дэн Боне (Стэнфордский университет) показали атаку, использующую измерение времени для различения размера межсайтовых ответов. В 2015 году исследователи из Университета Бар-Илан предложили модель поиска по сайту с анализом времени и размера ответа для повышения точности вытекания данных.

С 2010-х годов об атаках сообщалось и независимыми специалистами; например, в 2009 году Крис Эванс описал атаку на Yаhoo! Mail; в 2018 Луан Эррера выявил утечку в Google Monorail — баг-трекере, а в 2019 польский исследователь Terjanq реализовал утечку данных из сервисов Google.

В 2020 году Google анонсировал открытый проект XSLeaks Wiki для систематизации знаний о рисках и техниках межсайтовых утечек. В последние годы академическое сообщество стремится к формализации классификаций: в 2020 году была предложена система BASTA-COSI для обнаружения уязвимых URL, а в 2021—2023 годах опубликованы работы с новыми формальными моделями и развитием способов обнаружения, получившие специальные награды IEEE^[4].

Модель угроз при межсайтовой утечке подразумевает, что злоумышленник способен привести жертву на сайт, контролируемый им полностью или частично (например, путём размещения рекламы или внедрения вредоносного кода). Для атаки требуется выявить хотя бы одну URL на целевом сайте, поведение которой зависит от состояния сессии (например, выдаёт разные ответы для авторизованных/неавторизованных пользователей). Далее злоумышленник инициирует кросс-сайтовый запрос к этой URL, но direct-access к ответу блокируется политикой одного источника — остаётся анализировать косвенные признаки (например, HTTP-статусы, ошибки медиазагрузки, длительность).

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

Межсайтовые утечки представляют собой широкий спектр атакующих техник, и их классификация строится по используемому механизму утечки. Исследования к 2021 году выделяли более 38 техник, преимущественно затрагивающих механизмы браузера либо специфичные веб-API.

Данный тип атак основан на точном измерении временных характеристик выполнения запросов, событий загрузки и других процессов в браузере. Их впервые описали в Стэнфордском университете в 2007 году.

В 2017 году показано, что отсутствие строгой изоляции сайтов позволяет атакующему выявлять по задержкам исполнения JavaScript различия во внутреннем состоянии жертвы. В 2021-м исследователи продемонстрировали, что Performance API позволяет различать HTTP-редиректы по отрицательным значениям времени.

Эта техника позволяет выявить характер ответа сайта путём отслеживания, какие события ошибок возникли при загрузке контента. Например, если прикрепить обработчики onload и onerror к элементу, можно определить, возникла ли ошибка HTTP, получить её тип и даже узнать о длине медиаконтента.

Один из самых ранних вариантов межсайтовой утечки — анализ наличия нужного ресурса в кэше браузера с использованием кросс-доменных запросов. В 2014 году показана возможность геолокации пользователя через анализ кэша локализованных сайтов. После 2015 года стали возможны атаки с увеличением размера кэшируемого ответа и точным определением состояний пользователя.

Данный класс атак (также pool-party) оперирует не очевидным состоянием приложения, а ресурсными лимитами ОС или браузера — например, числом одновременных соединений или обработчиков событий. Замеряя разницу при активации этих лимитов, атакующий способен получить сведения о глобальном состоянии браузера.

Возможно использование потери фокуса окна, hash-части URL, заголовков Cross-Origin-Opener-Policy, количества вложенных фреймов и данных объекта window. Часть классических методов утратила актуальность после изменений в спецификациях W3C и внедрения механизмов защиты браузерами.

Типовой пример: веб-приложение на Python реализует REST-endpoint поиска по шаблону Jinja. Для каждого результата выводится изображение-иконка с CDN и описание. Приложение аутентифицирует пользователя по cookie и выдаёт результаты поиска по GET-параметру; каждый найденный документ сопровождается отдельной иконкой.

<html lang="en">
<body>
<h2>Search results</h2>
   {% for result in results %}
   <div class="result">
      <img src="//cdn.com/result-icon.png" />
      {% result.description %}
   </div>
   {% endfor %}
</body>
</html>

К этому коду применяется атака JavaScript-скриптом:

let icon_url = 'https://cdn.com/result-icon.png';
iframe.src = 'https://service.com/?q=password';
iframe.onload = async () => {
     const start = performance.now();
     await fetch(icon_url);
     const duration = performance.now() - start;
     if (duration < 5) // ресурс из кэша
         console.log('Query had results');
     else
         console.log('No results for query parameter');
};

Этот фрагмент встраивается атакующим в страницу, после чего жертва загружает целевое приложение в iframe, и скрипт измеряет время загрузки иконки с CDN: если иконка кэширована, значит, поиск дал результат и был как минимум один выводимый объект. Если время велико — результата нет. Так атакующий узнаёт о приватных данных пользователя.

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

Современная защита строится на расширениях HTTP-протокола, которые либо делают запросы межсайтовыми/без состояния, либо изолируют используемые ресурсы.

Классика межсайтовых утечек — анализ кэша браузера. Сейчас ведущие браузеры внедряют partitioned HTTP cache (разделённый кэш), что минимизирует эффективность техники: кэш браузера учитывает сайт, запросивший ресурс, и не раскрывает другим сайтам сведения.

Другой механизм — заголовки вроде Cross-Origin-Opener-Policy (COOP), изначально предназначавшиеся для борьбы со Spectre, которые также позволяют ограничить доступ из чужих контекстов. Кроме того, применяется полный partitioning всех видов хранения (cookies, localStorage и пр.), что затрудняет межсайтовую перекрёстную индикацию состояния.

Ограничения типа X-Frame-Options, инструкции content-security-policy: frame-ancestors, CORB и CORP позволяют жёстко задавать, с каких сайтов разрешено или запрещено встраивание, что закрывает часть каналов межсайтовых утечек.

Самой эффективной мерой считается использование параметра SameSite для cookie-файлов. В режимах Lax или Strict браузер не отправляет cookie при кросс-сайтовых запросах, делая их без состояния. С 2020 года Chrome устанавливает SameSite=Lax по умолчанию. Однако даже в этом режиме есть способы обхода защиты (например, техника LAX+POST). Контрмеры дополняются HTTP-заголовками Sec-Fetch-Site и другими метаданными fetch-запросов, позволяющими серверу различать легитимные запросы и вредоносные попытки.