Вот и 2 часть про атаки на веб-кэш. Ранее я писал про обман веб-кэша, где основная идея была в том, чтобы заставить кэш сохранить приватный ответ пользователя и потом получить к нему доступ. Ознакомиться можно ниже: ➥ https://setka.ru/posts/019eea71-b0ab-77b3-a80a-021f96c8e344

Сегодня тема тоже про кэш, но с другим смыслом — Web Cache Poisoning, или отравление веб-кэша.

━━━━━━━━━━ В чём суть Web Cache Poisoning ━━━━━━━━━━

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

То есть здесь цель не украсть приватный ответ жертвы, как в Web Cache Deception.

Здесь цель другая: ➤ заставить кэш раздавать другим пользователям ответ, который был заражён нами.

Web cache poisoning выступает не как самостоятельная “финальная” уязвимость, а как усилитель для других багов: • XSS • open redirect • подмена импортируемых ресурсов • опасная обработка заголовков • DoS

━━━━━━━━━━ Главная идея атаки ━━━━━━━━━━

• найти ввод, который влияет на ответ бэка ➤ К примеру поисковая строка, создание комента, …

• убедиться, что кэш не учитывает этот ввод в ключ кэша ➤ Ключ кэша это по сути id для понимания есть ли уже закешированный ответ на проксе/CDN

• добиться, чтобы вредный ответ попал в кэш ➤ К примеру передать не 1 параметр а 2 и 2 будет учитывать сервер но не кэш. Пример GET /lenta?search=fruit?search=berry для кэша есть только 1 параметр это search=fruit и он кэширует, но для сервера есть и 2 параметр и он отдаёт уже данные по search=berry и 2 параметр имеет уязвимость к xss позволяющую нам закинуть сохранённую атаку в параметр search=fruit

Вот здесь появляется важный термин — unkeyed input. Это часть запроса, которую backend может использовать, но cache при этом не учитывает при определении “одинаковых” запросов.

Например: • нестандартный заголовок • параметр • cookie • порт • часть URL, которую backend и cache понимают по-разному

Если сервер реагирует на это значение, а кэш его игнорирует, появляется пространство для poisoning/отравления.

━━━━━━━━━━ Два больших направления ━━━━━━━━━━

PortSwigger делит такие атаки на две темы с лабами.

➤ Проблемы в проектировании кэша Когда сам дизайн кэширования позволяет не учитывать опасные части запроса, хотя backend на них реагирует. К примеру воздействие на место откуда идёт загрузка контента через заголовок X-Forwarded-Host

➤ Проблемы в реализации кэша Когда кэш и бэк по-разному нормализуют URL, параметры, заголовки или части запроса. Пример с поисковой строкой и двойным параметром search

━━━━━━━━━━ Как я подходжу к поиску ━━━━━━━━━━

У меня такой flow: • найти страницы, которые кэшируются при помощи карты в burp • смотреть на Cache-Control, Age, X-Cache, Vary • проверять, что входит в ключ кэша • искать параметры и заголовки, которые влияют на ответ при помощи интрудера и Param Miner

━━━━━━━━━━ Мини-итог ━━━━━━━━━━

Я написал данный пост/статью благодаря PortSwigger Web Security Academy, а именно web-cache-poisoning. Так что, кого я заинтересовал, могут перейти к ним и более глубоко изучить, какие заголовки и методы разделения параметров могут помочь выявить уязвимость. А на превью стоит решение одной из лаб в этой теме. ➥ https://portswigger.net/web-security/web-cache-poisoning

#AppSec #PortSwigger #BugBounty #Pentest #WebSecurity #CyberSecurity