I think you’re mistaken OvermindDL1. When website A opens a connection, that doesn’t give any other website access to that connection. Now website B could open its own connection with the same server, but, unless I’m mistake, that would not give it access to cookies scoped to website A. Cookies aren’t passed in any part of a websockets payload, only the HTTP request that sets up the websocket would have access to cookies and just like any other HTTP request, the cookie would be scoped to the domain that issued the cookie.
dgmcguire
OvermindDL1
I never said it did.
I never said it would give Website B access to Website A’s cookies, I said it would give it access to a websocket that was initialized with those cookies, which based on if the server reads cookies then it could give Website B authenticated access to do stuff via that user, but it never exposes the cookies to Website B, just to the webserver via Website B.
Except starting a websocket connection to Website A from Website B javascript will send the HTTP request to webserver A, Website A’s cookies and all, which if webserver A decided to auth a user based on the cookies then Website B now has a fully authenticated websocket connection to do with what it pleases.
EDIT: It’s similar to a CSRF attack, where a ‘different’ site has a form that submits to ‘your’ site to do something (like say delete your bank information or whatever) that is then submitted with your users credentials, even though it was Website B that initialized the request, except with websockets it could be a lot worse without that token.
0
dgmcguire
A websocket and a connection are the same thing in this context. I don’t think I’m understanding you.
If website B does not have access to website A’s cookies and website A authenticates based on that cookie - then how would website B ever authenticate on website A?
0
OvermindDL1
Because the browser itself sends the cookie along, just like via a CSRF attack, especially worse because websockets don’t have same-origin cookie security:
As well as:
Now phoenix ‘could’ potentially fix it and allow access to cookies again if it validates the Origin header only.
1
dgmcguire
Oh, thanks for clearing that up for me - I didn’t realize website B would send website A’s cookies!
With that said, phoenix does currently validate against allowed origins - so this still should be secure to allow cookies to be used to authenticate, no?
1
OvermindDL1
Supposedly there are other issues that I don’t remember of off-hand, maybe @josevalim or @chrismccord remember?
0
josevalim
Creator of Elixir
This article explains the issue: Cross-Site WebSocket Hijacking (CSWSH)
If website A opens up a websocket to website B, then the browser will send all cookies and authentication headers that belong to website B, even though the request was made from A.
This is orders of magnitude worse than CSRF. CSRF is a blind attack, you can trigger it but you can’t read the result. On the other hand, CSWSH gives the attacker full control of the socket, you can read from the socket, write to the socket, and perform any other operation available through the socket.
Note Phoenix does validate the Origin by default. Still I don’t think we should allow cookies to be read. Messing this up opens up a very big vulnerability and Phoenix is correct in making it double sure it can’t happen. All of the information you want to pass as a cookie can be passed in a safer way.
If your site is exposed to XSS, then it is game over anyway, because with XSS you can directly open up a websocket connection without relying on CSWSH. So you shouldn’t worry about storing those in meta or local storage since XSS allows you to cause much more damage than what the token is meant to prevent.
4
OvermindDL1
The thing that I really exceptionally don’t like though is that almost all examples show doing this by stuffing the token into the HTML/javascript source somewhere, which loses a LOT of the natural security of cookies, and yet still other examples stuff it into the cookie that javascript then pulls out of, but then that means you can’t have the cookie be httponly, also losing some of its natural security, thus sure you can pass in the information via other ways, just none with as high of security as a cookie.
2
dgmcguire
I don’t think I understand why we wouldn’t prevent both XSS and CSWSH when we can. I agree that it’s possible to mess up and that phoenix should have safe defaults (and it does), but why would we expose ourselves to increased XSS attack surface when we could prevent both?
Phoenix already has safe defaults for preventing CSWSH and while it’s true that a compromised script could create a websocket connection and compromise you with a very phoenix-centric attack - I think it’s much more likely that a malicious script just leaks high attack surface details such as non-http cookies, meta tags, headers, etc.
My use-case is that I would like to be able to use the cookie for both http auth and websocket auth…I can’t do that confidently if I know I’m exposing that cookie to XSS and I don’t think we have to expose it to XSS.
I think the scenario where malicious JS is copy/pasting information to a 3rd party is much more likely than a malicious script sneaking in that creates websocket connections and executes domain specific logic.
I guess tl;dr; - we already have safe defaults preventing cswsh so why wouldn’t we be encourging people to use http only cookies to decrease xss attack surface?
3
josevalim
Creator of Elixir
Because if you are vulnerable to XSS, then you have already lost control over the socket, regardless if the token is stored in a cookie, meta or local storage.
1