Manipulating the WebSocket handshake to exploit vulnerabilities

 In this lab, the vulnerability is demonstrated through a live chat feature that relies on a WebSocket connection for real-time communication. When the user clicks “Live chat” and sends a message, the browser establishes a persistent WebSocket session with the server. Using Burp Suite, this traffic can be observed in the WebSockets history tab, where each chat message appears as a WebSocket frame being transmitted through the connection.

To begin exploring the application’s security controls, the WebSocket message is right-clicked and sent to Repeater. From there, the payload is modified to include a basic cross-site scripting attempt such as an image tag with an error handler, for example <img src=1 onerror='alert(1)'>. When this modified message is resent through the WebSocket channel, the application responds by blocking the payload. More importantly, the WebSocket connection is immediately terminated, indicating that some server-side filtering or intrusion detection mechanism is actively monitoring for malicious patterns and reacting by closing the session.

After the connection is dropped, attempting to reconnect reveals an additional defensive mechanism: the server now refuses new WebSocket connections from the same client. In Burp Suite, clicking “Reconnect” shows that the connection fails because the client’s IP address has been temporarily banned. This suggests that the application is implementing reactive IP-based blocking in response to detected malicious WebSocket activity, likely triggered by the attempted XSS payload.

To bypass this restriction, the WebSocket handshake request is modified before reconnecting. A custom HTTP header is added to the handshake: X-Forwarded-For: 1.1.1.1. This header is commonly used in proxy environments to indicate the original client IP address, but in insecure configurations it can be trusted by the backend server without proper validation. By spoofing this header, the server is tricked into believing the request originates from a different IP address, effectively bypassing the IP-based ban and allowing the WebSocket connection to be successfully re-established.

Once the connection is restored, another attempt is made to exploit the message handling logic. This time, instead of using a straightforward payload, an obfuscated XSS vector is used, such as <img src=1 oNeRrOr=alert\1`>`. The obfuscation changes the casing of the event handler and uses an alternative JavaScript syntax to bypass naive pattern-based filters that likely blocked the earlier attempt. When this message is sent through the WebSocket, it successfully bypasses the server-side filtering and is processed by the application.

When the payload is rendered in the browser context, the image fails to load and the obfuscated onerror handler executes, triggering JavaScript execution. This confirms that while basic filtering and IP-based blocking mechanisms are in place, they can be bypassed through handshake manipulation and payload obfuscation. The root issue lies in the fact that security decisions are being enforced inconsistently—first at the message level, then at the connection level—without a unified or robust validation strategy.

This lab highlights an important lesson in WebSocket security: defensive mechanisms applied after connection establishment, such as IP bans or simple pattern filtering, can often be bypassed if the handshake process itself is not securely designed. If headers like X-Forwarded-For are trusted without validation, and if input filtering relies on weak pattern matching, attackers can combine handshake manipulation with obfuscated payloads to regain access and successfully execute client-side code.