Accessing cookies in Phoenix.Socket connect

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 Likes