Re: [hybi] Extensibility mechanisms?

[Willy Tarreau <[e-mail]>]

Hi John,

On Thu, Jul 22, 2010 at 10:12:01AM -0400, John Tamplin wrote:
> On Thu, Jul 22, 2010 at 10:07 AM, Willy Tarreau <[e-mail]> wrote:
> 
> > > 1) Hostile JS code running in the browser may use the browser's WebSocket
> > client code to try to attack existing HTTP resources, if it can make a
> > request that looks sufficiently like HTTP.
> >
> > Maybe I'm mistaken, but why couldn't such JS code simply make use of the
> > browser's HTTP client to do so ? Posting a form, reloading an image from
> > a given URL or making an XMLHttpRequest seems perfectly possible right now,
> > so trying to do that via the WebSocket code would bring nothing at all.
> 
> JS is limited in how it can influence all the HTTP headers in the request,
> and is also bound by same-origin policy.

OK thanks for this clarification.

> > > 3) Hostile JS code running in the browser may use the browser's HTTP
> > client code (e.g. via XMLHttpRequest) to try to attack newly created
> > WebSocket servers, if it can make a request that looks sufficiently like
> > WebSocket.
> >
> > The same is true here : why would the JS code try to use the normal HTTP
> > client if the browser supports WebSocket, with which the code would be
> > able to have finer control over its attack ?
> 
> 
> The JS cannot control anything but the data contents of the message, so is
> limited in what it can do to the headers of the initial request or the
> framing.

Fine, so by making use of a same low-level protocol (HTTP), we're certain
that what is forbidden by one is also forbidden by the other one. In short,
if JS cannot manipulate HTTP headers, this will be true for both WS and HTTP
as long as WS handshake relies on HTTP. However, having a WS handshake that
"looks like" HTTP opens the way to corner cases and side effects (exactly
what happened with the extra bytes which can be parsed as HTTP requests
when directed to non-WS aware servers).

Regards,
Willy