Accessing cookies in Phoenix.Socket connect

It looks like Socket doesn’t have access to cookies because Transport.connect doesn’t accept the conn:

It also looks like the socket stuff is hooked directly into Cowboy, and doesn’t go through the normal plug stack, so there’s nothing I can do on my end to fudge the cookies into params.

Does this sound correct?

Is this worthy of opening an issue with Phoenix?

In general you should pass it to the socket constructor in javascript, and I’m still not sure of a good way. I currently create a token on the phoenix side holding the information I need then dump that into the generated html itself (Ick ick ICK) and grab that from javascript to stuff in to the socket. I really really wish we had access to the cookie information in a websocket to verify a token straight that way…

No, since this is an intentional design decision. WebSockets are not restrained by the same-origin policy, so using cookies could actually leave folks vulnerable to the xss you are wanting to avoid. We also don’t support them because channels are transport agnostic, and not all transports would support cookies. The recommended approach is to use Phoenix.Token to sign data into a token, then verify it on the server as a replacement for cookies. This works across any transport and client.

Hear hear, though there is one thing that would be really nice, if the javascript library could pull the token out of something in the page that is not HTML, like a cookie that is not htmlonly but is only a token and enforced that way or so? ^.^

I should do that to mine, I really really hate putting tokens ‘in’ the html, a lot of people like to save a page I’ve found and that can work around…

Is CSWSH the attack that blocking cookies on websockets prevents?

Looks like it, good read.

Apologies for the zombie thread, but I’m not sure I understand the rationale for not providing the option of reading cookies in the socket connect handshake.

It’s my understanding that a considerably safer method for storing and sending an auth token is via a HttpOnly cookie (provided you have CORS policies to prevent CSRF / CSWSH). With this, JS cannot access the tokens, and the browser does the storing / sending.

I understand the CSWSH concern due to lack of default CORS policy, but that sounds more like a strong warning to developers to check the origin, rather than just not supporting it at all.

On the flip side, we could pass a Phoenix.Token / JWT as a socket connection param, but the problem is that you have to get it to the socket constructor somehow. A <meta /> tag, localStorage, window.__INITIAL_STATE__, etc., are all easily accessible via JS (and therefore in a XSS attack).

So some clarification on this would be helpful.

I agree with this assessment. HttpOnly is vulnerable to CSRF as it always is, but it should be used complemented with a CSRF token or an Origin check. The current approach (write a token as a meta tag) would work well for CSRF in concert with an HttpOnly cookie, but I agree that on it’s own it’s vulnerable to XSS attacks. Any cross site JS script that runs on the page can access the meta tag and be used to initiate an authenticated web socket connection no?

oops, didn’t realize I was necro’ing such an old thread - sorry!

I don’t understand the security concerns here. The browser will send the cookie regardless of what phoenix decides to do with it, so I’m guessing the reason the cookie isn’t exposed on the socket connection is simply a matter of aiming to be transport agnostic, right?

If that’s the case what transports would you think might be unaware of HTTP? Because right now both implementations (long-polling and websocket) require an HTTP request to setup the channel.

Further I think that it’s a security concern that we aren’t exposing the cookie to developers. Without the ability to use HTTPOnly cookies you necessarily open the attack surface that a user might unintentionally send their clients malicious javascript, that javascript now has the ability to hijack your cookie or JWT or whatever else is exposed to the clients JS including tokens put in tags, correct?

Because I believe it to be increased attack surface, I would think a better and recommended authentication method would be to send unique HTTPOnly cookies to clients on any prior responses, so that when they are ready to upgrade to a websocket they can use that HTTPOnly cookie on the server to associate some authenticating data to their unique HTTPOnly cookie, thus ensuring the connection made was made with a trusted client.

Actually the issue is that you are logged in to Website A that uses a websocket that auths based on WebSite A’s cookie, then Website B sets up a websocket connection to Website A, which uses Website A’s cookie to authenticate as you, but then Website B can do whatever it wants to on that websocket now while using your credentials, all without you doing anything but just browsing and loading Website B. It really is a misdesign in the spec that websockets bypass cookie protention like that…