Отравление веб-кэша возникает только тогда, когда вредоносный ответ попадает в кэш и потом отдаётся другим пользователям.
Базовая логика проверки:
1️⃣ Понять, кэшируется ли ответ: если ответ вообще не попадает в кэш, poisoning не сработает
2️⃣ Найти часть запроса, которую кэш не учитывает: это часть запроса, которая влияет на ответ, но не входит в cache key
Например: заголовок, параметр, cookie или путь, которые меняют поведение origin-сервера, но игнорируются кэшем.
3️⃣ Проверить влияние на ответ
Найденная часть запроса должна приводить к «опасному» результату: отражению вредной строки, подмене ссылки на скрипт, перенаправлению, изменению meta-тега, ошибке 500 или другому поведению с понятным импактом.
4️⃣ Проверить, отдаётся ли отравленный ответ другим пользователям
Если изменённый ответ видите только вы, это ещё не полноценное отравление кэша. Нужен сценарий, где тот же кэшированный ответ получает другой клиент.
Главное правило при тестировании: всегда используй cache buster.
Например:
?cb=random-value
Но cache buster должен попадать именно в ключ кэша. Если кэш не учитывает строку запроса, случайный параметр в URL не поможет: можно получить false negative или случайно затронуть реальных пользователей.
Что проверять в отчёте:
✅ Как долго живёт отравленная запись в кэше
✅ получают ли её другие пользователи
✅ Зависит ли импакт от региона или CDN-ноды
✅ Влияет ли баг на конфиденциальность, целостность или доступность
✅ Можно ли безопасно воспроизвести проблему без вреда для пользователей