Re: [hybi] CONNECT handshake text

[Adam Barth <[e-mail]>]

On Wed, Dec 8, 2010 at 1:13 AM, Greg Wilkins <[e-mail]> wrote:
> 2010/12/7 Adam Barth <[e-mail]>:
>> Unmasking the Host header has some security risk.  The scenario we're
>> worried about is one in which the attacker and the target server are
>> virtually hosted on the same machine.  In that case, a machine that
>> does not understand the Host header is likely to route the request
>> according to the Host header, but not understand that it is
>> establishing a bidirectional tunnel.  Another approach to mitigating
>> this threat is to mask the payload data so the attacker won't be able
>> to trick the machine after the handshake completes.
>
> is the following description the attack vector that you are concerned about:
>
> www.innocentbystander.com and www.drevil.com are virtually hosted on
> the same machine
>
> A client loads some of drevil's javascript that makes a WS connection
> to www.drevil.com, which is routed to that virtual host and the WS
> connection is accepted.    www.drevil.com and/or the drevil javascript
> then send WS packets that contain spoof HTTP requests that are sent to
> www.innocentbystander.com   allowing the attacker to bypass same
> origin rules etc.

Yes.

> If the server hosting these domains is WS aware, then this is not a problem.

Correct.

> If the server is not WS aware, then we have to ensure that the
> handshake is not something that can be accepted by a normal HTTP
> server, no matter what application the drevil is running.
>
> The Hello frames that I have proposed protect against this kind of
> attack, because they are bytes that an application running on a
> non-websocket-aware server cannot generate, thus they cannot trick the
> client into accepting the WS connection and sending more bytes.
>
> Also robust WS framing is another layer of defence as it would protect
> any packets sent by the client from easily being interpreted as HTTP.

The issue with that approach is now you're exploring the error states
of the server rather than confining yourself to a syntax for which we
can predict the server's behavior.  It's likely that existing servers
have a wide variety of error states, and it's difficult for us to be
certain of how they behave.

> Thus regardless of using CONNECT of Get+Upgrade,  I believe my
> proposals for Hello frames and inverting some bits the header are good
> defences to include.   I've attached my proposed text/diff for them
> again... please feel free to swap out Upgrade for CONNECT if that is
> your preference.

Thanks for your willingness to compromise.

Adam