Re: [hybi] Web sockets and existing HTTP stacks

[Maciej Stachowiak <[e-mail]>]

On Feb 3, 2010, at 9:56 AM, Roberto Peon wrote:

> 
> 
> On Wed, Feb 3, 2010 at 2:02 AM, Maciej Stachowiak <[e-mail]> wrote:
> 
> On Feb 3, 2010, at 1:07 AM, Roberto Peon wrote:
> 
> >
> > How exactly does the random bit of text in the first line help?
> 
> In the case of a cross-protocol attack against HTTP, it's likely harder to inject text into the status line than it is to inject a response header, so that's the reason why it is in the first line. In the case of a cross-protocol attack against other protocols, in general it's harder to mess with the very beginning of the server response than the end (though not always).
> 
> The text is not random, it is a hash of some information from the request. The reason for the particular nature of the bit of text is to further increase the challenge of cross-protocol attacks by requiring the handshake response to contain something that (a) cannot be predicted before client JS tries to initiate the connection; and (b) is not a verbatim echo of anything in the handshake request. So even if you can find a server that will echo back exact text of your choice, or pieces of the request of your choice, you cannot make it return what appears to be a valid handshake response.
> 
> You can still do this as an HTTP header.

Indeed! And that was my original proposal. But I have been advised that the status line could afford stronger protection.

>  
> 
> > You still have to frame the HTTP response, which means that any errors in that framing are going to be causing problems.
> 
> I don't understand what kinds of problems you have in mind, could you clarify?
> 
> HTTP header injection problems: If it is possible, you can get interesting things to happen. This true of anything which is attempting to frame HTTP, and thus isn't limited to WebSockets, however, when it happens on a server there is no way to recover safely. The real problem with these is that the server has no idea that it happened without scanning its own output to see that it is framed the way it expects (and I don't know of any server which does this).

My proposal (both the header version and the status line version) should be effective at protecting normal Web servers from WebSocket even if there is a header injection vulnerability; likewise it should still help protect WebSocket servers from HTTP. Even if you can trick the server into injecting a header in its response, you can't predict the nonce, so you can't make it return a correct handshake.

>  
> 
> > In other words, the response will always be as insecure as HTTP. No way around that while still using HTTP. And, as we've already covered, not using HTTP isn't a terribly good option while on port 80 until the upgrade has finished.
> 
> Again, I don't know what you mean by "as insecure as HTTP". Specifically what we're worried about here are cross-protocol attacks (both using WebSocket and against a WebSocket service). The fact that the handshake format is an HTTP request does increase the risk in both directions, but we can do things to mitigate it. If you think my proposed defense is ineffective, could you explain how?
> 
> MitM still works just fine even with the hash value.
> What is the attack vector that you see mitigated? I may just not be seeing it.

Cross-protocol attacks, either using WebSocket from the browser to attempt to talk to plain HTTP another protocol; or using vanilla HTTP (via cross-site XMLHttpRequest) to attempt to talk to WebSocket. I explained both in detail in an earlier message.

Regards,
Maciej