- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 29 Mar 2011 15:12:04 -0700
On Tue, Mar 29, 2011 at 10:34 AM, Adam Barth <w3c at adambarth.com> wrote: > In this HyBi thread: > > http://www.ietf.org/mail-archive/web/hybi/current/msg06951.html > > Folks are arguing that the WebSocket protocol should support HTTP > redirects during the handshake and that dealing with the security > consequences of redirects should be dealt with at the API layer. > If/when that occurs, we should update the API layer to deal with the > security consequences of the WebSocket protocol following HTTP > redirects, preferably by aborting any WebSocket connections that the > server attempts to redirect. I absolutely agree that redirects are a big source of security problems. If we are going to support them for websocket then I think we need to learn from the mistakes of http as to not repeat the problems that occurred there. One solution could be to add a redirect API on the WebSocket interface. By default we would not follow the redirect but instead fire an event on the WebSocket object. The event would contain the URL which the server wants to redirect to. Only if the page explicitly signals that it wants to follow the redirect would we do so. This signaling could be done by calling .preventDefault() on the event, or by calling some .yesPleaseFollowRedirect() function on the event. It could also be done by making the implementation close the websocket object before firing the event, but allowing the page to call .open on the object and pass in an arbitrary url, for example the url which was received from the redirect event. But I'm totally fine with punting on this for the future and just disallowing redirects on an API level for now. / Jonas
Received on Tuesday, 29 March 2011 15:12:04 UTC