DOM XSS через location.hash и innerHTML

# DOM-based XSS через фрагмент URL ## Сценарий Вы — инженер безопасности **WareWave**, магазина портативной электроники. Тестировщик пожаловался на фичу каталога «ссылки-фильтры»: клиентский скрипт читает фрагмент адреса (часть после решётки), декодирует его и показывает наверху списка метку применённого фильтра. Жалоба была о «плавающих кавычках», но вам передали её целиком — проверить, чем именно скрипт вставляет текст в страницу, прежде чем фича уедет в мобильное приложение как образец. ## Цель 1. Изучите клиентский скрипт каталога и подтвердите: декодированный фрагмент адреса попадает в страницу через свойство, разбирающее строку как HTML, а не через текстовое. 2. Сконструируйте адрес с фрагментом, при открытии страницы исполнение которого в браузере жертвы доставит её cookie на ваш Exploit Server. 3. Отправьте адрес боту-администратору через форму отчёта, перехватите его сессию и заберите CTF-флаг из админ-раздела. ## Теория Фрагмент URL — часть после решётки — не покидает браузер: сервер его не получает, а значит, ни серверное экранирование, ни защитные заголовки, ни сетевые экраны к этой атаке отношения не имеют. Вся история — в клиентском коде, и решает одно различие: каким способом текст попадает в DOM. **Уязвимый паттерн:** ```javascript var decoded = decodeURIComponent(hash.substring(1)); el.innerHTML = '<p class="text-muted">Filtering by: ' + decoded + '</p>'; ``` Значение фрагмента склеивается со статической разметкой и присваивается свойству, которое разбирает строку как HTML и создаёт настоящие элементы. Теги исполнения скриптов из фрагмента становятся живыми узлами страницы и срабатывают с её правами — включая доступ к cookie сессии. ## Точка входа атаки Любая страница каталога `GET /catalog` с фрагментом в адресе: метка фильтра строится целиком в браузере. Доставка боту-администратору — `POST /report` с полем `url`. * **Обычный пользователь:** `demo` / `demo`