Re: [hybi] A WebSocket handshake

[Greg Wilkins <[e-mail]>]

On 6 October 2010 09:15, Adam Barth <[e-mail]> wrote:

> == Strawmen ==
> If  the attacker can host an htaccess file at any location a target HTTP server,

This is indeed a strawman.

If the attacker can host an htaccess file in any location, then the
attacker already owns the server!

> Consider, for example, a virtual hosting environment in which the attacker can place PHP scripts on the server.

Then again, the attacker already owns the server. They can write a
script to echo back any cookie or content from any script or XHR, so
the clients cookies are already been exposed.  This has nothing to do
with websockets.



> === Handshake Request ===
> 1) The attacker cannot influence any of the bytes included in the
> message.

If the attacker cannot influence any of the bytes in the handshake,
then an extra round trip will be needed to communicate the WebSocket
URL and subprotocol. Ideally these need to be known before a server
proceeds with accepting a websocket connection.

Thus I think it is unrealistic to propose a content free handshake.

Unfortunately, once you allow content (which I think we must), then a
CONNECT handshake is just as vulnerable to cross protocol attacks to
DNS servers as HTTP is.  If those servers are going to interpret the
method as a frame header and then scan forward to the arbitrary
content provided by the attacker, then they will be equally vulnerable
to POST, GET or CONNECT (with perhaps some variance due to the happen
stance of the actual ascii values of those names).   But luckily, you
have already demonstrated that DNS like servers are not vulnerable to
HTTP with GET and POST, so they are thus not vulnerable to CONNECT.
But this proposal still does not represent any real change of
substance.


> 2) Any intermediaries that understand this message according to its
> HTTP semantics with route the request to a non-existent domain and
> fail the request.  In particular, they will not route the
> Sec-WebSocket-Key to the attacker, making it difficult for the
> attacker to perform actions based on the key.

So that would mean that an intermediary that correctly implements both
CONNECT and
upgrade headers would not be able to work with websockets using this
handshake, while it could with the currently proposed handshake.

I don't think we should have a handshake that punishes correctly
implemented intermediaries.


> 4) This message cannot be generated by a web attacker in today’s browsers.

I expect this is true, although I would like to review the various
auto proxy configuration mechanisms that are available, as they may
allow a compromised CONNECT request.


> == Conclusion ==
>
> We believe this handshake is superior to the current handshake because
> this handshake has a stronger argument for security.  Because the
> attacker cannot control any of the bytes sent by the browser, the
> attacker will have difficulty mounting a cross-protocol attack using
> this handshake.

The strawman analysis of the threat to the upgrade handshake is indeed
a strawman and thus can't be used to justify any claims of
superiority.

Also the main security aspect of this handshake is that it does not
allow attacker supplied content.  This provides a secure but
non-functional handshake.