Reflected XSS в поиске магазина

# Reflected XSS в поиске каталога ## Сценарий Вы — специалист безопасности **ModulMart**, магазина компьютерных комплектующих. Служба поддержки получила жалобу: клиент перешёл со «скидочной» ссылкой на страницу поиска магазина, и после этого из его сессии кто-то попытался оформить заказ. Адрес ссылки потерян, но инцидент-ответчики попросили вас проверить, нельзя ли использовать сам поиск магазина как орудие атаки на посетителей — тем более что у магазина есть форма «Report to Admin», по которой администратор открывает присланные ему адреса. ## Цель 1. Найдите место, где поисковый запрос отражается в HTML-ответе, и подтвердите: разметка из запроса исполняется браузером, а не выводится текстом. 2. Сконструируйте запрос, исполнение которого в браузере жертвы доставит её cookie на ваш Exploit Server. 3. Отправьте боту-администратору адрес страницы с этим запросом, перехватите его сессию и заберите CTF-флаг из админ-раздела. ## Теория Reflected XSS — отражённый ввод: то, что пользователь передал в параметрах, возвращается в разметке страницы и исполняется в его браузере. Шаблонизатор фреймворка экранирует вывод по умолчанию, поэтому в чистом виде ошибка встречается редко — чаще защита для конкретного значения отключена намеренно, «чтобы форматирование поиска выглядело как надо». **Уязвимый паттерн:** ```html Showing results for “{{ query|safe }}” ``` Для отражаемого значения автоэкранирование шаблона явно выключено: строка из параметра попадает в разметку как есть. Скрипт, исполнившийся на странице, работает в контексте домена приложения — видит cookie сессии и может действовать от имени жертвы. Форма отчёта превращает это в атаку на администратора: бот открывает присланный адрес в собственной авторизованной сессии. ## Точка входа атаки `GET /catalog` с параметром `q` — отражение запроса на странице результатов. Доставка боту-администратору — `POST /report` с полем `url`. * **Обычный пользователь:** `demo` / `demo`