3 ms·

The problems and some security implications of websockets

42 points by subudeepak 12y ago

leeoniya 12y ago
"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.
- subudeepak 12y ago
  I doubt you are the first one ;) .. I was shocked when I discovered this myself.
- subudeepak 12y ago
  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.
  - jkarneges 12y ago
    There is mention in the spec: https://tools.ietf.org/html/rfc6455#section-10.2 https://tools.ietf.org/html/rfc6455#section-10.2 Is this not enough?
    - subudeepak 12y ago
      The Origin header is used to protect the server. This is to prevent the WebSocket Hijacking attack (http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html 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.
ENGNR 12y ago
Can't a malicious script scan the DOM and send sensitive info via an image GET request anyway?
- subudeepak 12y ago
  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.

42 points by subudeepak 12y ago

"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.

subudeepak 12y ago
I doubt you are the first one ;) .. I was shocked when I discovered this myself.
subudeepak 12y ago
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.
- jkarneges 12y ago
  There is mention in the spec: https://tools.ietf.org/html/rfc6455#section-10.2 https://tools.ietf.org/html/rfc6455#section-10.2 Is this not enough?
  - subudeepak 12y ago
    The Origin header is used to protect the server. This is to prevent the WebSocket Hijacking attack (http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html 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.

ENGNR 12y ago

Can't a malicious script scan the DOM and send sensitive info via an image GET request anyway?

subudeepak 12y ago
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.