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

[Greg Wilkins <[e-mail]>]

On 9 October 2010 10:03, Adam Barth <[e-mail]> wrote:
> This is a virtual hosting environment.  That's what I meant when I
> said "consider, for example, a virtual hosting environment in which
> the attacker can place PHP scripts on the server."  The attacker has
> access to one virtual host on the server but does not own the entire
> server.
>
> Concretely, consider http://www.adambarth.com/.  My web site is a
> virtual host on a physical server in a 1and1 datacenter.  I'm
> perfectly capable of placing a PHP script on my virtual host.  If the
> PHP script is able to complete the web socket handshake, then I can
> open a WebSocket connection to www.adambarth.com on port 80 from the
> user's browser.  Once the WebSocket handshake completes, I can now
> talk directly to the 1and1 server over more-or-less a raw socket,
> which means I can spoof further HTTP requests and potentially attack
> other virtual hosts that happen to be on the same physical machine,
> which is bad news bears.

Adam,

the key phrase in this description is "Once the Websocket handshake completes".
That just glosses over several defences:

 + It is not certain that the HTTP server will allow a PHP script to
generate a 101 response.
 + The HTTP server will not allow the PHP script to generate a WS ping
frame (or the unframed bytes of the current draft).
 + The HTTP server will not accept the pong response as a valid HTTP
request. This will almost certainly result in a 400 Bad request and
the connection being closed.

Currently there is no attack vector to get past these defences, other
than to assume that the server is already vulnerable to significant
attacks without the need to use a WS client.

Even if the handshake could complete - which it couldn't.  Then the
server does not have a more or less raw socket.  It has a WS socket
and only WS frames can be sent.  I am dubious that a valid websocket
frame could be a meaningful HTTP request.

However I do believe that this is very good exercise that we should do
- examine if it is possible to form a WS frame that looks like a
GET/POST/PUT etc request.  We should also test how common servers
treat characters such as would be expected in a WS header.  There may
be some tweaks we can make to the framing (eg setting RSV bits to 1)
that will further reduce the possibility of WS frames looking like
HTTP requests/

I will try to find some time to do this analysis next week.

regards