7 comments

[ 3.1 ms ] story [ 28.2 ms ] thread
"WebSockets is a nightmare because it does not come under the Same-origin policy."

yes, i discovered this myself about a week ago.

i was surprised that i was able to connect to a localhost websocket when using an internal app on another domain. i expected this to fail and require CORS like XMLHttpRequest. after rejoicing briefly that i didnt need to whitelist it and was saving 2min, i was pretty terrified.

I doubt you are the first one ;) .. I was shocked when I discovered this myself.
Note that this is not an implementation problem but a problem in the general specification of websockets. So there is not going to be a solution to this issue until the specification itself is updated.
There is mention in the spec: https://tools.ietf.org/html/rfc6455#section-10.2

Is this not enough?

The Origin header is used to protect the server. This is to prevent the WebSocket Hijacking attack (http://www.christian-schneider.net/CrossSiteWebSocketHijacki...) . i.e. it does not help a lot in the browser end especially in the mashup scenario.

However, the lack of the same-origin policy in WebSockets makes the presence of the same-origin policy in XMLHttpRequests questionable. I am just talking about this part where the browser does not have to restrict a connection to any origin from a given website without even a need for a CORS like whitelist.

Can't a malicious script scan the DOM and send sensitive info via an image GET request anyway?
Yes. The malicous scripts can already do that. It has taken years to train people and educate them on adding suitable Content-Security Policy headers to prevent such violations without breaking the internet. Every modern technology (especially the XMLHttpRequest) has been more strict on the SOP. However, to introduce a new technology which is more effective than a simple XMLHttpRequest in such a manner that it does not follow SOP when there is no threat of breaking any existing websites is questionable at best.