Manipulating WebSocket messages to exploit vulnerabilities

In this lab, the vulnerability is explored through a live chat feature that uses WebSockets for real-time communication between the user and a support agent. The interesting part is not just that messages are sent in real time, but how they can be intercepted and modified in transit, which ultimately exposes a stored XSS issue.

The attack begins by opening the Live chat interface and sending a normal chat message. At this stage, the application behaves as expected: the message is transmitted instantly and appears in the chat window. However, under the surface, this message is not using a standard HTTP request. Instead, it is being sent over a persistent WebSocket connection.

To confirm this, Burp Suite is used as an intercepting proxy. Inside Burp, the WebSockets history tab shows that the chat message is indeed being transmitted through a WebSocket frame. This is an important observation because it confirms that the communication bypasses traditional HTTP request logs and instead flows through a continuous channel.

Next, a controlled test is performed to understand how the application handles special characters. A new message is sent from the browser containing a single < character. This is a classic test for HTML injection because it is the starting point of any HTML tag.

When this message is observed in Burp’s WebSockets history, it becomes clear that the application is not passing raw input directly. The < character has been converted into its HTML-encoded equivalent < before being sent. This indicates that some form of client-side encoding is taking place before the message is transmitted.

At first glance, this might suggest that injection is prevented. However, this assumption is misleading. Client-side encoding only protects the path before interception and does not guarantee security once the message is modified in transit.

To test this, WebSocket interception is explicitly enabled in Burp Proxy. With interception active, another chat message is sent. This time, instead of allowing it to pass unchanged, the intercepted WebSocket frame is manually modified before it reaches the server.

The original message content is replaced with the following payload:

<img src=1 onerror='alert(1)'>

This payload is significant because it does not rely on <script> tags. Instead, it uses an image element with an invalid source. The important part is the onerror event handler, which triggers JavaScript execution when the image fails to load.

After forwarding the modified WebSocket message, the application processes and distributes it like any normal chat message. However, when the message is rendered in the browser, the payload is interpreted as HTML rather than plain text.

As a result, the browser attempts to load the image, fails, and immediately executes the onerror handler. This triggers a JavaScript alert dialog, confirming successful code execution in the browser context.

What makes this vulnerability more impactful is that the same message is not only rendered for the attacker but also propagated through the WebSocket channel to other connected users. This includes the support agent’s browser session, meaning the payload executes in multiple contexts simultaneously.

The key issue revealed by this flow is that client-side encoding of < is not sufficient protection. Because the WebSocket message can be intercepted and modified after encoding, an attacker can bypass these protections entirely. The real failure occurs at the rendering layer, where the application inserts WebSocket message content into the DOM without proper sanitization or output encoding.