Эксплуатация изъянов дизайна кэша
В этом разделе мы узнаем, как уязвимости Web Cache Poisoning возникают из-за общих изъянов в дизайне кэшей, и покажем, как их эксплуатировать.
Коротко: сайты уязвимы к отравлению кэша, если они небезопасно обрабатывают не ключевые компоненты запроса и позволяют кэшировать последующие HTTP-ответы. Эта уязвимость может служить методом доставки для разных атак.
Использование отравления кэша для доставки XSS
Классический вектор для эксплуатации уязвимости — когда не ключевой компонент отражается в кэшируемом ответе без должной очистки.
Например, рассмотрим такой запрос и ответ:
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: innocent-website.co.uk
HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://innocent-website.co.uk/cms/social.png" />Здесь значение заголовка X-Forwarded-Host используется для динамической генерации URL изображения Open Graph, который затем отражается в ответе. Критично для отравления кэша, что X-Forwarded-Host часто является не ключевым. В этом примере можно потенциально отравить кэш ответом с XSS-нагрузкой:
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://a."><script>alert(1)</script>"/cms/social.png" />Если этот ответ будет закэширован, все, кто зайдёт на /en?region=uk, получат XSS. В примере это просто alert, но реальная атака может красть пароли и захватывать аккаунты.
Использование Web Cache Poisoning для эксплуатации небезопасного импорта ресурсов
Некоторые сайты используют не ключевые компоненты запроса, чтобы динамически генерировать URL для импорта ресурсов, например внешних JavaScript-файлов. В таком случае, если атакующий сменит значение нужного заголовка на домен под своим контролем, он может заставить ссылаться на свой вредоносный JS.
Если ответ с этим URL закэшируется, файл атакующего будет импортирован и выполнен в сессии любого пользователя с совпадающим ключом кэша.
Использование Web Cache Poisoning для эксплуатации уязвимостей обработки cookie
Cookie часто применяются для динамической генерации содержимого ответа. Типичный пример — cookie, указывающая предпочитаемый язык, на основе которой подгружается соответствующая версия страницы:
В этом примере запрошена польская версия поста. Обратите внимание, что информация о языке содержится только в заголовке Cookie. Предположим, что ключ кэша включает стартовую строку и заголовок Host, но не Cookie. Тогда если ответ будет закеширован, все последующие пользователи, открывшие этот пост, получат польскую версию, независимо от выбранного ими языка.
Такое некорректное обращение к cookie кэшом тоже можно эксплуатировать. На практике, однако, это встречается реже, чем отравление через заголовки. Когда уязвимости на базе cookie существуют, их обычно быстро находят и чинят, потому что пользователи случайно отравляют кэш.
Эксплуатация уязвимостей Web Cache Poisoning с использованием нескольких заголовков
Некоторые сайты уязвимы к простым векторам эксплуатации, как выше. Другие требуют более сложных атак и становятся уязвимыми лишь при манипуляции несколькими не ключевыми компонентами.
Например, допустим сайт требует HTTPS. Если приходит запрос с другим протоколом, сайт динамически генерирует редирект на себя же по HTTPS:
Само по себе это поведение не обязательно уязвимо. Но в сочетании с рассмотренными ранее уязвимостями в динамически генерируемых URL атакующий может сгенерировать кэшируемый ответ, перенаправляющий пользователей на вредоносный URL.
Эксплуатация ответов, раскрывающих лишнюю информацию
Иногда сайты повышают уязвимость к отравлению кэша, «выдавая» слишком много сведений о себе и своём поведении.
Директивы Cache-Control
Одна из задач при построении атаки — добиться кэширования вредоносного ответа. Это часто требует проб и ошибок. Однако порой ответы прямо содержат нужную информацию.
Например, ответы могут сообщать, как часто кэш очищается, и насколько «стар» текущий сохранённый ответ:
Это не ведёт напрямую к уязвимости, но экономит атакующему время ручной работы, поскольку он знает, когда именно отправить полезную нагрузку, чтобы она попала в кэш.
Эти знания также открывают путь для более тонких атак. Вместо спама к бэкенду до срабатывания, атакующий может аккуратно рассчитать момент для одиночного отравленного запроса.
Заголовок Vary
Примитивный способ использования заголовка Vary тоже может помочь атакующему. Vary перечисляет дополнительные заголовки, которые следует считать частью ключа кэша, даже если обычно они не учитываются. Часто туда включают User-Agent, чтобы мобильную версию сайта не отдавали не-мобильным пользователям.
Эта информация позволяет строить многоэтапные атаки на конкретные сегменты пользователей. Например, зная, что User-Agent — часть ключа кэша, атакующий может сначала определить User-Agent жертв и «нацелить» атаку только на них. Либо выбрать самый популярный User-Agent для максимального охвата.
Эксплуатация DOM-уязвимостей с помощью Web Cache Poisoning
Как обсуждалось, если сайт небезопасно использует не ключевые компоненты, в виде заголовков запроса, для импорта файлов, это может позволить импортировать вредоносный файл. Это относится не только к JavaScript.
Многие сайты используют JavaScript, чтобы запрашивать и обрабатывать дополнительные данные с бэкенда. Если скрипт небезопасно обрабатывает данные сервера, это может приводить к DOM-уязвимостям.
Например, атакующий может отравить кэш ответом, который импортирует JSON-файл с следующей нагрузкой:
Если сайт передаст значение этого свойства в приемник (sink), поддерживающий динамическое выполнение кода, нагрузка выполнится в контексте браузерной сессии жертвы.
Если вы используете Web Cache Poisoning, чтобы заставить сайт загрузить вредоносный JSON с вашего сервера, может понадобиться дать сайту доступ к JSON при помощи CORS:
Цепочки уязвимостей Web Cache Poisoning
Как мы видели, иногда вредоносный ответ удаётся получить лишь при составлении запроса с несколькими заголовками. То же верно и для разных типов атак. Отравление кэша порой требует «сцепить» несколько техник. Комбинируя уязвимости, можно раскрыть дополнительные слои уязвимости, изначально казавшиеся неэксплуатируемыми.
Last updated