5 ms·
Surprisingly often websocket connections are made to a different domain from what is serving the site itself. I'm not sure about the root cause to the pattern,
by bostik 6y ago
Surprisingly often websocket connections are made to a different domain from what is serving the site itself. I'm not sure about the root cause to the pattern, but sure as hell know that our company has been doing it at least since 2013.
Browsers set the "Origin" header for ws:// calls, and the websocket servers are expected to check that. Without the check, it'd be possible to issue blind writes (CSRF) from random webpages to the ws:// endpoints. If you're using main site authentication with a separate websocket domain and auth'd requests, all garden variety security scanners will flag the separate websocket domain as a problem, and only the robust ones actually try to validate the server side configuration.
Disclosure: I have triaged and responded to a few of such reports.
- oefrha 6y agoConnecting to a different domain is fine, that's what CORS is for. Letting any origin connect by default -- that's a problem. > Browsers set the "Origin" header for ws:// calls, and the websocket servers are expected to check that. I know that, but as always insecure by default protocols are terrible, and are guaranteed to be exploited beyond recognition... The question is why not be secure by default and force servers to whitelist origins they expect to talk to?
- marcosdumay 6y ago> Surprisingly often websocket connections are made to a different domain from what is serving the site itself. That's probably because websockets require asynchronous servers optimizing for number of active connections, while normal sites are best served by servers optimized for response time. Of course, you can have both handled by the same origin, but it's not the blatantly obvious way.