3

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
Improve this question
8
  • Did you consider in your tests that modern browsers by default restrict the scope of a cookie, so that it cannot be used cross-site unless explicitly defined by the server setting the cookie? See SameSite attribute. So you would need to use SameSite=None (which requires use of Secure attribute which then means to use TLS, i.e. HTTPS/WSS)
    – Steffen Ullrich
    Jul 6 at 19:29
  • I had the same suspicion, too. However, I already mentioned that I tested with SameSite=None. See my post above.
    – sherlock
    Jul 6 at 19:33
  • Do you use HTTPS though when setting the cookie? Secure=False suggests not and is apart from that not a valid cookie attribute (there is only Secure, nothing with true or false). To cite from what I linked to: "Note: A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites (http:) can't set cookies with the Secure directive, and therefore can't use SameSite=None."
    – Steffen Ullrich
    Jul 6 at 19:56
  • Sorry. Writing Secure=False wasn't probably the best way to indicate that the cookie is not secure, and therefore can be sent over HTTP, which is what I used throughout the test.
    – sherlock
    Jul 6 at 20:27
  • FYI, I linked the demo app in my post in case you or anyone else wants to play with it
    – sherlock
    Jul 6 at 20:36

1 Answer 1

Reset to default
3

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .