Re: [hybi] Web sockets and existing HTTP stacks

[Vladimir Katardjiev <[e-mail]>]

For reference, linking the message from Maciej with the problem statement. http://www.ietf.org/mail-archive/web/hybi/current/msg01198.html  

On 3 feb 2010, at 23.17, Maciej Stachowiak wrote:

>> 
>> You can still do [the nonce] as an HTTP header.
> 
> Indeed! And that was my original proposal. But I have been advised that the status line could afford stronger protection.

I can appreciate the logic in having the mandatory response before the request is able to manipulate the output. On the other hand, if the request has anyway successfully manipulated the first bytes of the output to state "HTTP/1.1 101 Web Socket Protocol Handshake", it stands to reason that a couple of more bytes at the end of that won't pose much of a difficulty for an attacker. (Alternatively, the remote host is a WebSocket aware endpoint, at which point you don't have a cross-protocol vulnerability anyway).

In any event, assuming the nonce is unpredictable, the only case in which an unaware server can be tricked into sending back a correct response is if the client is able to make the server compute it. Since this is tantamount to executing arbitrary code on the server, I'd say that's a case that can't be combated, as arbitrary code can always send back the proper response.

For the second case, I don't see at all why this would help on a websocket server that doesn't validate input data... or on a websocket server at all. Since the nonce is opaque to the server, why can't I just send something that pretends to be a nonce from my xhr? It should properly parse, as long as it's [a-zA-Z0-9]+ and the server will happily reply. But it stands to reason if you don't validate your input you're open to attacks. The best you can do is always force the WebSocket server to validate the handshake (which, if I'm not mistaken, you're arguing anyway?)

Vladimir