5 ms·
WebSocket is great But not the origin policy
- BarkMore 14y agoThe Origin header can be used to protect against CRSF. It's OK that the header is not useful for much more than this important task.
- arunoda 14y agoI'm not a security expert. Does CRSF also works with WebSockets? How it can be prevented using Origin header?
- BarkMore 14y agoDoes CRSF also works with WebSockets? The browser sends cookies in the websocket handshake. If the server application uses the cookies for authentication, then a malicious web site can act on behalf of a user without the user's knowledge. How it can be prevented using Origin header? The server application can reject requests originating from other sites.
- arunoda 14y agoThanks. I'm clear now.
- chime 14y agoIf you want to secure WebSockets, use WSS. More info: http://blog.kaazing.com/2012/02/28/html5-websocket-security-is-strong/ http://blog.kaazing.com/2012/02/28/html5-websocket-security-...
- arunoda 14y agoThis seems interesting. Thanks.
- wanderr 14y agoIt would be nice if there were a better, more reliable way to do this, but it's consistent with how the rest of the web works. We use heuristics to try to detect rogue/fake clients, and hellban them.
- afhof 14y agoI must be mistaken because this looks like a nonissue. Servers are not ever expected to trust client provided data. The origin header is optional for non web services which means that servers probably won' be too picky about this field. This just looks like the analog to the "Referer" field. Is there a security issue I'm not seeing here?
- arunoda 14y agoNo. There is no security issue. But I just tried to point out that is there any use of Origin header? Or tried to learn if it does something which I didn't get?
- justinschuh 14y agoThe purpose of the origin header in WebSockets is to implement any capabilities that require verification of the requesting origin. This is, of course, valid only in the context of a legitimate client to server connection (since origin security is meaningless in any other context). So, for example, you could use the origin header to protect against confused deputy vulnerabilities (which are known as CSRF in standard HTTP). You could also use the origin header to implement your own cross-origin access control in a scenario where XHR/CORS is not appropriate or efficient (e.g. an embeddable chat widget).
- arunoda 14y agoYes. Now I got it. It does(can be) prevent if CSRF happens. Since Referer header is not sent by all the browsers, Origin can be used. - http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html http://people.mozilla.org/~bsterne/content-security-policy/o...
- justinschuh 14y agoThis post represents a gross misunderstanding of origin security on the Web. Protection against a malicious client is an explicit non-goal of origin security, if not an outright impossibility. To put it another way, if the client is already compromised, then what can you possibly do at the server to protect it anyway?