Labs Covered

This write-up focuses on the following PRACTITIONER-level labs from the PortSwigger Web Security Academy related to WebSockets:

2 Cross-site WebSocket hijacking

This lab demonstrates how attackers can hijack WebSocket connections across origins, exploiting trust relationships and insecure implementations.

3 Manipulating the WebSocket handshake to exploit vulnerabilities

This lab shows how attackers can manipulate WebSocket handshake headers to exploit vulnerabilities during connection establishment.

---

LAB 2 - Cross-site WebSocket hijacking

Lab Description

What is Cross-Site WebSocket Hijacking?

Cross-Site WebSocket Hijacking (CSWSH), also known as Cross-Origin WebSocket Hijacking, is a vulnerability that results from a CSRF flaw in the WebSocket handshake process.

How It Works

• The vulnerable application uses HTTP cookies for authenticating WebSocket connections.
• It does not implement CSRF protection such as tokens or unpredictable headers.
• An attacker creates a malicious web page on a different origin.

• When a victim user (who is already authenticated) visits the attacker’s page:

  • A WebSocket connection is made from the attacker’s page to the vulnerable application.
  • The server accepts the handshake because it trusts the cookies automatically sent by the browser.

  • The attacker can now:

    • Send arbitrary WebSocket messages as the victim
    • Receive and read responses from the server

Impact

• The attacker achieves two-way interaction with the server in the context of the victim’s authenticated session.

• This can lead to:

  • Unauthorized actions on behalf of the user
  • Sensitive data leakage
  • Full session compromise

---

Solution

The lab application is a shop website offering chat support. After loading the page, I go straight to the chat feature and start chatting with the agent:

The next thing is to look at the handshake to see how the WebSocket is established:

There is a single identifying feature in the request, the session cookie, without any protection against CSRF attacks. The cookie is automatically sent by the browser. If I create my own web application that utilizes this WebSocket, I can therefore use this connection to perform any action and read any data the victim has access to. What is also noteworthy is that once the WebSocket connection is established, the server sends the full history of the chat. This is noticeable on the chat page. No matter how often I reload the page, the full chat history is displayed.

If I can utilize this connection to retrieve the chat content of my victim, I may be able to find useful information.

Craft malicious application

Let’s start the malicious application. The WebSocket page on javascript.info provides a good example to follow. The chat always starts with a READY message, so I reproduce this.

Once I open the page, I get my full chat history displayed:

Option 1: Burp Collaborator

As a first option, I can exfiltrate using the Burp Collaborator. This requires a Burp Suite Professional license but is very convenient. See option 2 below for the non-Burp Pro solution.

This does not prevent the exfiltration of the chat data as it refers to the connection to the collaborator URL, not the WebSocket. In my Burp Collaborator client, I get all my chat history.

If I want to get rid of these error messages, the documentation on mozilla.org leads to the RequestMode. Setting this to no-cors stops the errors.

After delivering the exploit to my victim, I check the Burp interactions and see some:

The messages are out of order, but going through the requests the following conversation is visible:

Option 2: Exploit Server Log

As an alternative to Burp Suite Professional, I can also use the Access Log feature of the exploit server. For this, I need to replace the fetch URL with my exploit server:

After delivering the exploit to the victim, the chat contents are visible in the Access log of the exploit server:

whichever way was used to obtain username and password, using them allows me to log in to the application and the lab updates to solved

---

LAB 3 - Manipulating the WebSocket handshake to exploit vulnerabilities

Lab Description

Overview: What is Cross-Site WebSocket Hijacking?

Cross-Site WebSocket Hijacking (CSWSH) is a vulnerability that allows an attacker to hijack a user’s authenticated WebSocket session.

Key Concept:

It exploits a lack of CSRF protection during the WebSocket handshake—when authentication is based only on cookies, without verifying any unpredictable tokens.

How it works:

1. The victim is authenticated on a vulnerable website using cookies.
2. The attacker lures the victim into visiting a malicious site.
3. The malicious site uses JavaScript to initiate a WebSocket connection to the target application.
4. Because cookies are automatically sent, the server treats the connection as authenticated.
5. The attacker now gains two-way communication with the server in the victim’s session context.

Impact:

• Full control over WebSocket-based features
• Read and send messages as the victim
• Potential data leakage or account compromise

---

Solution

First I intercept the WebSocket request on client side.

I think these type of payload is block and that have blocked our ip.

So add x forwarded header so it will change our ip.

Now if we give same payload above it will block our ip ,So we have change our paylaod Now it will trigger alert and lab will be solved.