Ваш сайт пропускает конфиденциальную информацию?

Не уделялось внимания XSLeaks (межсайтовым утечкам), которые приводят к утечке пользовательской информации.

Большинство разработчиков знакомы и осведомлены об уязвимостях безопасности XSS (межсайтовый скриптинг), CSRF (подделка межсайтовых запросов) или SQL Injection, но XSLeaks (межсайтовый утечки), что может привести к утечке пользовательской информации. В этом блоге я собираюсь дать краткое введение в него.

Что такое XSLeaks?

XSLeaks — это класс уязвимостей, когда сторонний вредоносный веб-сайт может отправлять запросы или перенаправлять пользователей к целевым службам, а затем измерять сигналы побочного канала (например, время ответа, статические кэши ресурсов в браузере, код состояния ответа HTTP, содержимое ответа). и т. д.) для вывода и сбора информации о пользователях на основе таких сигналов побочного канала.

Реальный пример: вы читаете мой блог, что, если я знаю, кто вы??

В 2013 году была обнаружена сообщенная ошибка, которая позволяла веб-сайту использовать Facebook для определения того, является ли посетитель конкретным человеком. Изображение предварительного просмотра для значка Facebook было динамически сгенерировано на основе идентификатора пользователя Facebook в то время. Если бы пользователь 1234567 вошел в систему, изображение выглядело бы примерно так, как на рис. 1. Если другие пользователи пытались загрузить изображение значка для пользователя 1234567, вместо изображения профиля загружалось изображение логотипа Facebook (рис. 2). По сути, только сам пользователь мог просматривать предварительный просмотр значка своего профиля.

‹img src="https://facebook.com/badge_edit.php?userid=1234567" /›

Несмотря на то, что Facebook хорошо заблокировал информацию об имени и адресе электронной почты, он все же утек идентичность пользователя. Хакер может использовать JavaScript для автоматической загрузки предпросмотра профиля для списка предопределенных идентификаторов пользователей, а затем проверить высоту и ширину изображения ответа, чтобы узнать, что конкретный пользователь просматривает свою страницу.

Если приведенный выше пример для вас сильно устарел, есть еще одна сообщенная ошибка середины 2018 года. Том Энтони открыл способ, с помощью которого можно было добиться аналогичного результата. Сегодня большинство серверных конечных точек Facebook хорошо защищены по сравнению с 2013 годом, они загружены access-control-allow-origin, x-frame-options headers, чтобы предотвратить внедрение вредоносного веб-сайта и исследование контента FB с использованием запроса XHR, iframe, тега изображения и т. д. Однако Том обнаружил, что один API (с идентификатором пользователя в качестве параметра) дает разные content-type для совпадающего и не совпавшего пользователя. Затем он использовал простой сценарий JavaScript, который брал список идентификаторов пользователей и генерировал множество тегов script с src равными конечной точке. Теги script, конечно, не работают, но они ошибаются по-разному из-за различий в типах содержимого ответа, и это можно обнаружить с помощью обработчиков событий onload и onerror. Кроме того, похоже, что для этой конечной точки не было никаких ограничений скорости, и он мог проверять тысячи идентификаторов за минуту.

Если бы вышеуказанные ошибки не были исправлены, люди могли бы использовать их для преследования определенных людей (например, начальника, бывшей девушки, знаменитостей и т. д.), читающих их блоги, или они могли бы показывать различное содержимое в зависимости от того, кто посещал их. Больше реальных примеров атак XS-Leak можно найти здесь.

Как защищаться?

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

Параметры X-Frame

Использование X-Frame-Options: DENY приводит к сбою любой попытки загрузить вашу страницу во фрейм. Он не только защищает от кликджекинга, но и помогает защититься от XSLeaks. Если страницу необходимо встраивать в другие сайты (реклама, виджеты и т. д.), содержащаяся на ней информация должна быть максимально постоянной и предсказуемой.

Файлы cookie того же сайта

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

Строгие файлы cookie того же сайта могут помочь избежать вышеуказанных случаев, поскольку они различают запросы, сгенерированные пользователем, который вручную вводит URL-адрес, щелкает закладку или щелкает ссылку с текущего сайта, и запросы, инициированные другими веб-сайтами.

Вы можете обратиться к этой ссылке для получения более подробной информации об этом виде атаки.

Получить заголовки запроса метаданных

Современные браузеры реализуют заголовки sec fetch, чтобы предоставить серверам больше информации об обстоятельствах, почему и где был инициирован запрос. Эта информация помогает серверам быстро отклонять запросы на основе проверки набора предварительных условий.

Например, запрос, сгенерированный элементом img, приведет к запросу, содержащему следующие заголовки HTTP-запроса:

Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

Сервер может реализовать проверку политики для конечной точки и быстро отклонить запрос контента, не связанного с изображением, с помощью Sec-Fetch-Dest.

Выводы

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