On Feb 2, 2010, at 2:31 PM, Justin Erenkrantz wrote:
> Yes, I admit it'd be a bit helpful if the nonce proposal was little
> more concrete.

Let me start by laying out the security risks in the current handshake. Then I will explain my proposed change and how I believe it addresses them.


1) Hostile JavaScript could use WebSocket for a cross-protocol attack against vanilla HTTP resources or non-HTTP servers.

If the attacker can trick a non-WebSocket server into echoing back chosen text (for example through something in the URL part of the request), then they could make it give what appears to be a valid WebSocket handshake response. This could result in unauthorized access.

The current handshake attempts to mitigate this, by requiring some fixed parts of the response after the status line; thus, the fixed part of the handshake response effectively includes newlines. Since none of the parts of the request controlled by client JS can contain literal newlines, this somewhat increases the difficulty of echoing back exactly the right handshake. However, this is weaker than it could be. The exact correct handshake response is fully predictable, and furthermore consists only of fixed parts and verbatim repetition of parts of the request.

While we do not know of any service that is currently vulnerable, if the correct handshake response could not be predicted by client JS, that would be much more robust. And we do know that cross-protcol attacks from Web browsers are a real issue in general.


2) Cross-site XMLHttpRequest (using CORS or XDomainRequest) could be used for a cross-protocol attack against WebSocket resources, potentially violating integrity (though not confidentiality).

The WebSocket protocol currently does not require any checking of the client handshake. However, any WebSocket server that performs any side effects in response to messages from the client has a security vulnerability if it does not check correctness of the handshake request from the client. A cross-site XMLHttpRequest facility could be used to send a request to the victim an HTTP request with a body that looks like one or more valid WebSocket messages. This request would be a POST instead of a GET, and would lack the required WebSocket headers. But if the server is not checking, it would happily chug along.

The server would, of course, not respond with the right CORS headers needed for the attacker to actually read the response, so confidentiality cannot be violated. However, if the server treats incoming client messages as commands, then there is no protection against violating integrity.

To give a concrete example, consider a chat service over WebSocket. Let's say it doesn't check correctness of the handshake, and does authentication in-band. An attacker could construct an HTTP POST body which would look like an authentication message plus a couple of submitted sent messages. True, the attacker cannot read the victim's chat messages, but could send chat messages as the victim. Clearly this would be a significant security breach.

Admittedly, the spec could be changed to require servers to check some aspects of client handshake correctness. But because they can give a correct response without any processing, it remains relatively easy to forget to do this. A handshake protocol that required the server to read the client's request would reduce the risk.

Ian argued that services which do not read messages from the client at all (perhaps a data stream service like a stock ticker) would face an extra burden without gaining any safety from such a requirement. However, pure data stream services are easier to do via EventSource anyway; EventSource deals with intermediaries and can work with a completely unmodified Web server. So I don't think WebSocket needs to put a lot of weight on that use case.


Suggested solution:

We could mitigate both of these risks, and also reduce the implementation difficulty for servers and proxies, by changing the handshake. We would remove the requirement for newlines or exact capitalization of the headers. Instead, we could have the browser generate a unique random nonce, which it includes in the handshake request. The server would be required to read it, and respond with a hash of the nonce value. 

This has two benefits: (a) client JS can no longer predict the exact text of a valid handshake response; and (b) servers are essentially forced to look at the handshake, and must look for at least one element that cannot be forged with cross-site XMLHttpRequest. Thus, this mechanism mitigates risks (1) and (2) above. The reason to respond with a hash of the nonce, instead of the nonce literally, is so the response includes something that is both unpredictable *and* not a verbatim echo of any part of the request. There is no need for the hash to be cryptographically strong.

There are many possible variants, but here is an example of what the handshake request and response could look like (the hash used here is MD5; we could use a weaker hash that is faster to compute however):

Handshake from the client:

        GET /demo HTTP/1.1
        Upgrade: WebSocket
        Connection: Upgrade
        Host: example.com
        Origin: http://example.com
        WebSocket-Protocol: sample
        WebSocket-Nonce: 2d1283cf01e0e9f562989f0781450e7e

Response from the server:

        HTTP/1.1 101 Web Socket Protocol Handshake
        Upgrade: WebSocket
        Connection: Upgrade
        WebSocket-Origin: http://example.com
        WebSocket-Location: ws://example.com/demo
        WebSocket-Protocol: sample
        WebSocket-Nonce-Hash: 8ba7ca1e53376d29842e88d0f9db6978

The status line must come first, but order and capitalization of all request and response headers would be free. If we wanted to, we could even allow the status line to use any HTTP version.

A possible variant would be to include the nonce hash in the status line instead of in a header. But I think header is probably better.


Regards,
Maciej