4 ms·

This is why you don't let @wongmjane inject code into websites. Imagine what features she'd learn about with tracebacks from developer machines! /s In seriousn

by btown 6y ago

This is why you don't let @wongmjane inject code into websites. Imagine what features she'd learn about with tracebacks from developer machines! /s In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-cors-does-this-mean-2e7819374acc https://blog.securityevaluators.com/websockets-not-bound-by-... There's a simple fix though - hot reload websocket listeners like Webpack should only consider the connection valid if they first receive a shared secret that's loaded into the initial dev bundle, which itself would never be transmitted over a websocket and could be set via CORS to not be accessible to non-whitelisted origins. It's a dead-simple protocol with no ongoing performance impacts. But understandable it hasn't been implemented yet.

lstamour 6y ago
That’s exactly the solution I was thinking of. No end-user visible changes required, just change websocket to require a secret on initial connection. An easy way of doing this might be to use the web socket URL path or a query variable. Note that we’re relying on the websocket library code to do the right thing: https://tools.ietf.org/html/rfc6455#section-10.7 https://tools.ietf.org/html/rfc6455#section-10.7 Example, and note: https://news.ycombinator.com/item?id=23261309 https://news.ycombinator.com/item?id=23261309
vbezhenar 6y ago
Websocket protocol defines Origin header to indicate which website tries to establish connection. Hot reload websocket server must check it and allow localhost connections only (at least by default).
- lstamour 6y ago
  It might not be localhost or a local IP if users use a different hostname, common for some environments, at which point it would have to be configurable. But yes, that could also work, if all browsers send Origin headers as expected.
Ajedi32 6y ago
> In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-cors-does-this-mean-2e7819374acc https://blog.securityevaluators.com/websockets-not-bound-by-... As far as I can tell, that article only explains that WebSockets aren't bound by CORS. It doesn't provide a reason (good or otherwise) why WebSockets were designed that way. Personally, I consider that feature to be a design flaw. If WebSockets handshakes respected the Same-Origin-Policy and CORS headers the same way every other HTTP request on the web does, none of these vulnerabilities with poorly implemented WebSockets servers would exist today, as they would be secure by default rather than "insecure unless the server properly validates the origin header on every handshake". Probably too late to do anything about that anymore though. Changing WebSockets to respect the Same Origin Policy now would break a ton of websites.
- chrisfosterelli 6y ago
  It's a function of the natural evolution of things. The same origin policy was originally introduced with AJAX at a time when the vast majority of traffic was to the same origin. It wasn't a common pattern to make complex requests to a different domain (barring GETs and FORM posts which were allowed). Web development changed and it started to become more popular to make complex cross-domain requests, but the problem is they couldn't just throw out the SOP without introducing a massive security vulnerability to all existing sites. So instead CORS was introduced as an option to relax the SOP. With websockets being completely different, it was an opportunity to "start over". They opted to embrace cross-domain communication and require developers implement security on top of it. The `postMessage` API has done the same thing. Any window can `postMessage` to any other window -- it's fully up to the windows to validate the security of messages coming their way. Some argue that it's a bad idea to make "allow by default" the new paradigm. Personally, it seems pretty clear to me that developers just don't understand CORS at all [0], and letting the developers handle this in their own logic, while being exceptionally clear about this in the documentation, is a far more developer friendly and simple (therefore more secure) approach. [0]: https://fosterelli.co/developers-dont-understand-cors https://fosterelli.co/developers-dont-understand-cors
  - 6y ago

by btown 6y ago

lstamour 6y ago

That’s exactly the solution I was thinking of. No end-user visible changes required, just change websocket to require a secret on initial connection. An easy way of doing this might be to use the web socket URL path or a query variable. Note that we’re relying on the websocket library code to do the right thing: https://tools.ietf.org/html/rfc6455#section-10.7 https://tools.ietf.org/html/rfc6455#section-10.7 Example, and note: https://news.ycombinator.com/item?id=23261309 https://news.ycombinator.com/item?id=23261309

vbezhenar 6y ago

Websocket protocol defines Origin header to indicate which website tries to establish connection. Hot reload websocket server must check it and allow localhost connections only (at least by default).

lstamour 6y ago
It might not be localhost or a local IP if users use a different hostname, common for some environments, at which point it would have to be configurable. But yes, that could also work, if all browsers send Origin headers as expected.

Ajedi32 6y ago

> In seriousness, this is all because websockets aren't bound by CORS, for good reason. https://blog.securityevaluators.com/websockets-not-bound-by-cors-does-this-mean-2e7819374acc https://blog.securityevaluators.com/websockets-not-bound-by-... As far as I can tell, that article only explains that WebSockets aren't bound by CORS. It doesn't provide a reason (good or otherwise) why WebSockets were designed that way. Personally, I consider that feature to be a design flaw. If WebSockets handshakes respected the Same-Origin-Policy and CORS headers the same way every other HTTP request on the web does, none of these vulnerabilities with poorly implemented WebSockets servers would exist today, as they would be secure by default rather than "insecure unless the server properly validates the origin header on every handshake". Probably too late to do anything about that anymore though. Changing WebSockets to respect the Same Origin Policy now would break a ton of websites.

chrisfosterelli 6y ago
It's a function of the natural evolution of things. The same origin policy was originally introduced with AJAX at a time when the vast majority of traffic was to the same origin. It wasn't a common pattern to make complex requests to a different domain (barring GETs and FORM posts which were allowed). Web development changed and it started to become more popular to make complex cross-domain requests, but the problem is they couldn't just throw out the SOP without introducing a massive security vulnerability to all existing sites. So instead CORS was introduced as an option to relax the SOP. With websockets being completely different, it was an opportunity to "start over". They opted to embrace cross-domain communication and require developers implement security on top of it. The `postMessage` API has done the same thing. Any window can `postMessage` to any other window -- it's fully up to the windows to validate the security of messages coming their way. Some argue that it's a bad idea to make "allow by default" the new paradigm. Personally, it seems pretty clear to me that developers just don't understand CORS at all [0], and letting the developers handle this in their own logic, while being exceptionally clear about this in the documentation, is a far more developer friendly and simple (therefore more secure) approach. [0]: https://fosterelli.co/developers-dont-understand-cors https://fosterelli.co/developers-dont-understand-cors
- 6y ago