Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.

Overview

The exercise isolates a CSRF enforcement gap: the support sibling reflects Invalid user: ; injected script opens the support WebSocket, sends READY, and receives Carlos’s chat history. The important evidence is the browser’s cookie and navigation behavior, not merely that a cross-site form can be submitted.

Lab objective/setup

Exercise SameSite Strict bypass via sibling domain through the endpoint and input recorded in the lab note. The support sibling reflects Invalid user: <input>; injected script opens the support WebSocket, sends READY, and receives Carlos’s chat history.

What I observed

the support sibling reflects Invalid user: <input>; injected script opens the support WebSocket, sends READY, and receives Carlos’s chat history.

Lab description identifies cross-site WebSocket hijacking and requires exfiltrating the victim chat history to Burp Collaborator.
Lab description identifies cross-site WebSocket hijacking and requires exfiltrating the victim chat history to Burp Collaborator.
WebSockets history shows the `wss://.../chat` connection and the `READY` message that requests chat history from the support service.
WebSockets history shows the `wss://.../chat` connection and the `READY` message that requests chat history from the support service.
The live-chat HTML response contains the concrete sibling host `https://support-LAB.web-security-academy.net`, identifying the support origin in the same site.
The live-chat HTML response contains the concrete sibling host `https://support-LAB.web-security-academy.net`, identifying the support origin in the same site.
Browser cookie details show the application session cookie with SameSite=Strict.
Browser cookie details show the application session cookie with SameSite=Strict.
The support sibling-domain login page exposes username and password fields.
The support sibling-domain login page exposes username and password fields.

Why it is vulnerable

The support sibling reflects Invalid user: <input>; injected script opens the support WebSocket, sends READY, and receives Carlos’s chat history. The application passes that value into the security-sensitive operation without the context-specific validation or encoding needed to prevent this result.

Walkthrough in the authorized PortSwigger lab

Recreate the account-change flow, establish the normal request’s token and cookie requirements, then alter only the method, token presence, cookie age, redirect path, or sibling-origin step named in the evidence. The goal is to show exactly where the browser still supplies authority to the forged request.

A failed support login reflects the supplied username in the “Invalid user” response, establishing the injection point.
A failed support login reflects the supplied username in the “Invalid user” response, establishing the injection point.
A script payload in the reflected username executes on the support sibling, demonstrated by the JavaScript alert.
A script payload in the reflected username executes on the support sibling, demonstrated by the JavaScript alert.
The exploit-server body redirects to the support sibling with reflected JavaScript that opens the WebSocket, sends READY, and forwards messages to Burp Collaborator.
The exploit-server body redirects to the support sibling with reflected JavaScript that opens the WebSocket, sends READY, and forwards messages to Burp Collaborator.
Burp Collaborator records the exfiltrated WebSocket chat response containing Carlos’s credentials.
Burp Collaborator records the exfiltrated WebSocket chat response containing Carlos’s credentials.
The Academy page for “SameSite Strict bypass via sibling domain” shows Solved after logging in with the recovered account.
The Academy page for “SameSite Strict bypass via sibling domain” shows Solved after logging in with the recovered account.

Verification

The lab is confirmed when the support sibling reflects Invalid user: <input>; injected script opens the support WebSocket, sends READY, and receives Carlos’s chat history. The captured result and the Academy solved state provide the verification; an ordinary status code alone does not.

Impact and defensive lesson

A production attacker could change victim account data while relying on ambient cookies. Validate CSRF tokens on every state-changing route and method, bind them to the authenticated session, set deliberate SameSite attributes, and remove redirect or sibling-origin gadgets that turn same-site navigation into cross-site request authority.

References