Exactly my point, hence why it should be stored in the cookie. ^.^
OvermindDL1
josevalim
Creator of Elixir
Storing in the cookie opens up the possibility for CSWSH if you mess up your check origin configuration. Storing it elsewhere prevents from CSWSH and does not make it any better or worse when it comes to XSS. So I don’t see a reason to keep the cookie around.
0
OvermindDL1
Has phoenix messed up the check origin configuration? As I recall it takes explicit site domains or to be entirely disabled (which absolutely should not be default of course).
It is trivial for people to break XSS as well just by, oh, not putting in the CSRF check (very easy to do if adding phoenix to an existing project), that doesn’t mean that useful functionality should be denied outright when there are useful uses of it that are still as safe or more so as otherwise.
0
dgmcguire
Right, but you’ve lost control via a likely static asset - the attacker very likely doesn’t have arbitrary write access to your assets or else the attacker probably wouldn’t need a authenticated socket to do damage in the first place.
What’s much more likely is that a generic malicious ad or something runs a script on your website that crawls the page looking for sensitive information and passing that to a 3rd party that could later analyze that information and potentially use it later. In my case I want to use the same cookie for http auth and websocket auth - that means this highly generic malicious script could grab my cookie and at some generic point in the future use that cookie to hijack one of my users sessions.
Let’s compare that to an XSS vulnerability that would do malicious damage via a socket. First that script would have to be aware of how to connect to our server via a websocket. Secondly that script would have to know the websocket API in order to intelligently issue messages that would do harm. This isn’t something a generic script could do - that would either mean the application was specifically targeted or that the malicious user has write access to our codebase via some other vulnerability (maybe it’s sanitized params - maybe they have shell access as a user that has write privileges).
The difference here is that both of these attacks can happen now - whereas only the latter could happen if users were using http_only cookies to authenticate.
To be fair, I agree that exposing the cookie to developers does increase the attack surface for CSWSH, but I would personally be happy to go documentation hunting and changing everywhere that recommends using meta tags/tokens to an HTTP only cookie and explaining why it’s important not to mess up the server-side origin check for phoenix sockets.
I think it’s important to take advantage to closing off as much attack surface as possible in phoenix and I don’t think we can say that we’re doing that currently. My preference would be to allow access to http_only cookies and start educating everyone on how to make sure you aren’t vulnerable to CSWSH
0
dgmcguire
This code appears to outline that it has safe defaults that make you whitelist allowed domains. I haven’t dug into the functionality, but the error message would lead me to believe that is the case.
1
dgmcguire
To be more transparent - I’m working on a library that could really utilize http-only cookies for both http auth and websocket auth.
There are heavier ways to ensure my library would still be safe to use, but having http_only cookie access within the socket connect would really keep things simple and easy to explain to new users.
Essentially the library is trying to bridge the request/response nature of http but give the server push access via websockets - in order to achieve more parity it would be very beneficial to have one secure way to authenticate for both http and websocket upgrades.
1
josevalim
Creator of Elixir
As you can imagine, people do not follow the spec accordingly. Some tools like Cordova send file:/// as the origin, which means that to support Cordova, you open up a vector attack to anyone who would open an .html file via the filesystem.
How is XSS related to CSRF?
If your concern is custom scripts stealing your information, then the custom scripts could simply send a malicious version of the .js to the client. Any attack that starts with the premise of remote code execution is already more vulnerable than CSWSH.
You can always build your own transports. We won’t help you shot yourself in the foot though. 
2
josevalim
Creator of Elixir
Oh, nice to hear you are the one working on Texas! I am really looking forward to your talk at ElixirConf! 
1
OvermindDL1
I’ve never yet seen a non-browser websocket tool that doesn’t accept an origin request (in addition I’ve not seen any non-browser tool able to use the cookies from the browser either), and if something did not support stated an origin then I don’t see how it would work with any websocket conforming server implementation? Though I’ve never heard of Cordova so I’m unsure of how popular it is or what it’s use is either, but I still doubt it pulls the cookie from the browser as it is?
Eh just listing security examples, I was conflating form post injections and all together, rushing too fast due to lack of time to type here. ^.^
And right you aren’t by the origin check, shooting someone in the foot is their own doing and entirely outside of standard operating setup, but disallowing a standards based storage method is highly irritating regardless and I’m still not seeing the point in it.
0