⌨️Web Cache Deception - это веб-уязвимость, которая позволяет атакующему заставить кеш-сервер сохранить динамический запрос.
Немного базы: для быстрой загрузки статического контента многие приложения (особенно CDN) используют кеш-серверы. Работает это примерно следующим образом: пользователь делает запрос; кеш сервер, расположенный между приложением и пользователем проверяет, является ли запрашиваемая информация статической; в случае удовлетворения предыдущего критерия кеш-сервер сохраняет ответ от приложения.
В такой схеме, когда пользователь снова запросит тот же статический контент, кеш-сервер моментально его отдаст, что позитивно скажется на скорости загрузки сайта.
⌨️Тип: Web, Server-Side.
Уязвимость заключается в эксплуатации расхождений в интерпретации запросов кеш-сервером и приложением. Атакующий составляет запрос, в ответ на который основное приложение будет возвращать динамичееский контент (в некоторых случаях вместе с cookie), в то же время кеш-сервером данный запрос будет интерпретирован как статический и будет созранен. Данный запрос отсылается жертве. После перехода по ссылке, при последующем обращении атакующего по тому же ключу кеширования, будет получен динамический контент, сгенерированный для другого пользователя.
Чуть нагляднее на примере:
Пример полезной нагрузки:
http://example.com/profile;pwn.jsКакое тут расхождение? Мы видим, что запрос идет к загрузке профиля пользователя с некоторым разделителем ;. В случае, если данный символ не распознается приложением как часть запроса, приложение вернет динамический контент профиля пользователя. Если же кеш-сервером данный символ распознается как часть запроса и в нем имеется правило на сохранение .js файлов, он посчитает, что был запрошен какой-то js-скрипт и закеширует его. Так, если сначала по ссылке перейдет жертва с валидным аккаунтом, а затем атакующий, то он увидит контент профиля жертвы.
⌨️Влияние:
Получаение чувствительной информации других пользователей, Account Takeover.
Важно не путать эту уязвимость с Web Cache Poisoning, так как в данном случае мы не отравляем кеш вредоносной нагрузкой, а заставляем его сохранить динамическую информацию при помощи расхождений в интерпретации, то есть все запросы будут выглядеть чистыми.
⌨️Шаги эксплуатации:
- ⌨️ Определяем, используется ли кеширование (и пытаемся осознать как оно устроено)
- ⌨️ Определяем таргет (ответ с чувствительной информацией)
- ⌨️ Ищем расхождения с кеш-сервером
- ⌨️ Конструируем запрос и побеждаем
⌨️Как защититься?
- ⌨️ Использовать заголовок Cache-Control с директивами private и no-store
- ⌨️ Настроить в CDN запрет на перезапись заголовка Cache-Control
- ⌨️ Использовать специальные настройки в CDN для защиты от данного типа атак (некоторые такое умеют)
- ⌨️ Удостовериться в отсутствии расхождений в интерпретации запросов приложением и кеш-сервером
Честно говоря, на своей практике я очень редко встречал эту уязвимость. Возможно, потому что наше ПО дает недостаточно информации для определения принципов кеширования; возможно, потому что от этого легко защититься; возможно, потому что у нас в целом не так часто что-то кешируется на стороне сервера; возможно, потому что уязвимость новая и мало кто до конца понимает как оно работает. Так или иначе, ребята из Portswigger анонсировали на ближайший Black Hat крупный доклад, включающий новые вектора по этой уязвимости - возможно, там мы увидим развитие всей этой темы.
#edu #vuln #web #cache #cache_deception
Дискуссия