Re: [hybi] Web sockets and existing HTTP stacks

Vladimir,

I think that the idea is that the attacker is not able to pick the nonce and thus not able to
predict the response.

The attacker would trick some webuser to run their js, it would open a websocket connection
to some URL, but it would be the browser that thinks of the nonce, so even if the
attacker was able to inject arbitrary text into the response, they would not know the
nonce and would not be able to insert the correct hash.   The browser would see the
wrong hash and not complete the handshake.

I still think that this is putting too much responsibility on websocket to not be
usable to exploit an insecure server.   The security problem here is that the server
is injectable, not that websockets can be used to exploit it.    But then the nonce
proposal is really easy to implement, so there is little harm.

I'm also not convinced that if the browser was tricked into opening a websocket
to a HTTP server, that it could send any messages that would look like valid
HTTP requests.    If in doubt, then perhaps a few more fixed bytes on every
WS frame are needed.  If the bytes "WS" were sent before every message, then
nobody could spoof a "GET ..." or a "POST ..." - which I think is impossible
anyway with both length and sentinel framing.

But if anybody from chrome/mozilla/opera wants to experiment with the nonce,
I can have it implemented in the jetty server in about 10 minutes.

cheers

Vladimir Katardjiev wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi