Why is the browser not sending cookies with cross-domain WebSocket handshake request?

Question

If I have understood Cross-Site WebSocket Hijacking (CSWSH) attack correctly [1][2][3][4], the attack relies on two things (examples are from the first reference):

• the browser sending the cookies set by the victim domain (www.some-trading-application.com) over a WebSocket handshake request initiated from a JavaScript code running on the attacker domain (https://www.some-evil-attacker-application.com)
• no Origin header check being performed on the victim server side

The first happens due to the absence (by design) of cross-origin checks for WebSocket requests. I tested the hypothesis with a demo app that I developed. While the browser (Firefox 102.8.0esr (64-bit)) does permit cross-origin WebSocket requests, it does not send the auth_cookie cookie alongwith. For my test setup, I did the following:

• Pointed both victim.com and attacker.com to 127.0.0.1 by modifying /etc/hosts on a Ubuntu system
• Victim web app (which includes the WebSocket server, too) runs on victim.com:5000, and sets an auth_cookie with the most relaxed restrictions (HttpOnly=False, Secure=False, SameSite=None, Path=/)
• Attacker webpage runs on attacker.com:10000, and initiates a WebSocket handshake to victim.com:5000/logincheck, the vulnerable WebSocket endpoint. I made sure that the auth_cookie is set in the browser by victim.com before the WebSocket call is made from attacker.com.

Unfortunately, I could not see the auth_cookie being sent either from developer tools in the browser, or Burp proxy. I repeated the test with other Firefox and Chrome versions as well, but had the same result.

Does CSWSH even work on modern browsers?

References

1. https://christian-schneider.net/CrossSiteWebSocketHijacking.html
2. https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc
3. https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets
4. https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/cross-site-websocket-hijacking-cswsh.md

Answer 1

The browser is not respecting the SameSite=None flag, because the cookie is not Secure (and can't be, since it wasn't set via a secure context). MDN claims that the expected behavior is to reject such cookies outright, but browsers that aren't fully compliant with the current spec might do things like "ignore the SameSite flag and use the default value" (which has been "Lax" for some years now).

If you go to the dev tools in the browser and look at the list of cookies for the site (in Firefox's dev tools, this is under the "Storage" tab), what shows up? Is the cookie listed as SameSite: None, or some other value? (Is it there at all?) Also, when setting the cookie, do any errors appear in the console? MDN says that an error message should be logged.

A browser old enough to not support SameSite at all, or to not care whether the cookie is Secure or not when considering SameSite, will not run into this problem and will exhibit the vulnerability with your current app. For a modern browser, run the server (for both sites) on HTTPS and make the cookie Secure (and SameSite=None), and the browser should exhibit the vulnerability.