Re: [hybi] Handshake was: The WebSocket protocol issues.

[Willy Tarreau <[e-mail]>]

On Fri, Oct 08, 2010 at 05:43:06PM -0700, Eric Rescorla wrote:
> On Fri, Oct 8, 2010 at 5:39 PM, Scott Ferguson <[e-mail]> wrote:
> 
> > Bjoern Hoehrmann wrote:
> >
> >> * Scott Ferguson wrote:
> >>
> >>
> >>> So the attacker has a PHP script running on the same physical machine as
> >>> the target site, on the same VM guest as the target, and using the same
> >>> shared web server as the target, and has decided that a cross protocol
> >>> attack is the appropriate vector against a target on the same machine as his
> >>> PHP script.
> >>>
> >>>
> >>
> >> In the scenario the browser thinks it is talking Websocket while the
> >> server thinks the browser is talking HTTP, so basically
> >>
> >>  +----------------+                    +------------------+
> >>  | User's browser | -- "Websocket" +-- | attacker.example |
> >>  +----------------+                |   +------------------+
> >>                                  HTTP
> >>                                    |   +------------------+
> >>                                    +-- | target.example   |
> >>                                        +------------------+
> >>
> >> How attacker.example and target.example are organized is up to the
> >> web server, it could just be some kind of firewall where the two sites
> >> are actually hosted on physically separate machines behind it and they
> >> may be unable to talk to each other. I do think this is something that
> >> the Websocket protocol needs to address.
> >>
> >>
> >
> > To consider the original scenario, do you think the case where the
> > attacker's PHP script is on the same physical and virtual machine as the
> > target is something WebSockets needs to address? Or that the shared machine
> > configuration is already so compromised that complicating WebSockets to
> > address that scenario adds no real value.
> >
> >
> This case definitely needs to be addressed. It's a completely standard
> hosting
> configuration.

it is correctly addressed by respecting the HTTP protocol which consists in
sending Connection: close in the request so that there is no risk that either
the web server or any intermediary consider additional data as a second request.

Regards,
Willy