Здравствуйте, дорогие друзья.

Заражение веб-кэша — это метод, используемый злоумышленниками для принудительного выполнения кэширующими серверами вредоносных запросов. Чаще всего эта атака связана с self xss, которая превращает обнаружение xss с низким уровнем воздействия в обнаружение с высоким уровнем воздействия, поскольку оно может быть передано любому пользователю, который посещает кэшированную страницу.

Основные серверы кэширования

Чтобы понять, как происходит заражение веб-кэша, вы должны сначала понять, как работают серверы кэширования. Проще говоря, серверы кэширования работают, сохраняя запрос пользователя, а затем обслуживая этот запрос к другим пользователям, когда они обращаются к той же конечной точке. Это используется для предотвращения повторного обращения к одному и тому же ресурсу и принуждения сервера выполнять одну и ту же работу снова и снова. Вместо этого сервер вызывается только в том случае, если ответ не найден на сервере кэширования, поэтому, если конечная точка “test.com/cat.php” вызывается 100 раз, сервер ответит на первый запрос и сохранит ответ на сервере кэширования. На остальные 99 запросов кэширующий сервер ответит, используя сохраненный ответ от первого запроса.

Как показано выше, “пользователь 1” отправляет запрос на “example.com/kop?somthing=ok”, и ответ не найден на сервере кэширования, поэтому он перенаправляется на веб-сервер, который отвечает на ответ. Следующие пользователи 2 и 3 отправляют тот же запрос, но на этот раз ответ находится на сервере кэширования, поэтому с веб-сервером не связываются.  Вместо этого отображается старый ответ.

Как именно сервер кэширования определяет, идентичны ли два запроса? Ответ — ключи кэша. Ключ кэша — это индексная запись, которая однозначно идентифицирует объект в кэш. Вы можете настроить ключи кэша, указав, следует ли использовать строку запроса (или ее части) во входящем запросе для различения объектов в кэше.

Обычно в качестве ключей кэша используются только метод запроса, путь и хост, но могут использоваться и другие. Если мы посмотрим на приведенный выше запрос, то ключами кэша будут:

● GET /embed/v4.js?_=1605995211298

● Play.vidyard.com

Все остальное будет отброшено при определении того, являются ли два запроса одинаковыми, если не указано иное.

Как показано выше, в HTTP-ответе заголовок “Vary” указывает, что X-ThumbnailAB, Заголовки X-China, accept-language и Accept-Encoding также используются в качестве ключей кэша.

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

Заражение веб-кэша

Если злоумышленник может каким-либо образом внедрить вредоносный контент в http-ответ, который кэшируется, тот же ответ будет отправлен другим пользователям, которые запрашивают ту же конечную точку. Название «заражение веб-кэша» может показаться пугающим и сложным, но на самом деле его относительно легко найти и использовать.

Первый шаг — найти входные данные без ввода ключа. Как упоминалось ранее, ключи кэша используются кэширующим сервером для определения того, какие запросы совпадают, а какие отличаются. Нам нужно найти ключи, которые не заставят сервер думать, что запрос отличается. Отсюда и название “unkeyed”, потому что он не используется кэширующим сервером, поэтому он не будет использоваться для определения того, является ли запрос уникальным или нет. Второй шаг — определить, какое влияние оказывает ввод без ключа на сервер, можно ли его использовать для использования открытого перенаправления уязвимость, self xss или какая-либо другая уязвимость. Наконец, вам нужно выяснить, можно ли кэшировать страницу, используя ввод без ввода ключа, и если да, то вы сможете использовать других пользователей при просмотре кэшированной страницы.

Я упоминал, что первое, что вам нужно сделать, это найти ввод без ввода. Это можно сделать в Burp с помощью плагина “param miner”. После загрузки этого плагина вы можете легко запустить проверку, щелкнув правой кнопкой мыши по запросу и выбрав «param miner».

Далее будет отображена конфигурация атаки. Вы можете изменить настройки здесь, но обычно я просто нажимаю «ОК».

Примечание. Вы также можете использовать кнопку угадать заголовки, если вас интересуют только значения без ключа в заголовке, или вы можете нажать кнопку угадать getParameters, если вас интересуют параметры получения.

После нажатия кнопки “ок” атака начнется, и вы сможете просмотреть свои результаты на вкладке расширитель, как показано ниже:

Как показано выше, был найден заголовок “X-forward-scheme”, который не используется кэширующим сервером в качестве ключа. Этот заголовок также уязвим для XSS. В обычных условиях мы могли бы использовать только себя, но если полезная нагрузка self xss кэшируется приложением, другие пользователи смогут просматривать кэшированную страницу, если она общедоступна.

Просматривая HTTP-ответ, мы видим, что возвращается несколько заголовков, которые являются индикаторами кэширования страницы. Заголовок “X-Cache” имеет значение “hit”, что означает, что страница была обработана из кэша. Если было установлено значение “пропускать”, страница не будет загружена из кэша. Заголовок “Возраст” также является еще одним показателем того, что страница кэшируется. Это значение содержит количество секунд, в течение которых страница была кэширована. Очевидно, что нам нужно кэшировать полезную нагрузку self xss, поэтому попытка выполнить ее на конечной точке, которая уже кэширована, не сработает. Однако, как упоминалось ранее, путь обычно используется при определении того, является ли была ли страница кэширована или нет, поэтому добавление случайного параметра GET к запросу должно привести к кэшированию ответа.

Как вы можете видеть выше, изменение параметра GET “test” на “2” приводит к кэшированию ответа сервером. Этот вывод был сделан из того факта, что заголовок “X-cache” имеет значение “miss”, а заголовок “Age” — значение «0». Теперь мы знаем, что можем кэшировать ответ, увеличив значение параметра test. Теперь добавьте полезную нагрузку self xss в уязвимый заголовок “X-forward-scheme” и увеличьте значение параметра test еще раз. Наконец, нажмите «Отправить», и полезная нагрузка self xss будет кэширована сервером. Любой, кто просмотрит конечную точку, приведет к тому, что полезная нагрузка xss начнет эффективно переключаться, преобразуйте xss в сохраненный xss.

Резюме

Заражение веб-кэша — это относительно новая уязвимость, которая может показаться некоторым людям непонятной, но ею довольно легко воспользоваться. Найдите значение без ключа с помощью плагина param miner, посмотрите, сможете ли вы каким-либо образом использовать значение без ключа (self xss), посмотрите, сможете ли вы заставить сервер кэшировать вредоносный http-ответ, и, наконец, проверьте, сработал ли ваш эксплойт. Обычно люди игнорируют уязвимости self xss, но при отравлении веб-кэша вы можете превратить self XSS в сохраненный XSS.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.