Re: [hybi] Handshake was: The WebSocket protocol issues.

[Maciej Stachowiak <[e-mail]>]

On Sep 29, 2010, at 12:58 AM, Greg Wilkins wrote:

> On 29 September 2010 09:50, Maciej Stachowiak <[e-mail]> wrote:
> 
>>> + Reliance on the browser not treating the 101 response as an error.
>>> + The inability to read the ping frame after the 101 response.
>> 
>> The threat model I described involves an attack on integrity, not confidentiality, so these two defenses do no good.
>> 
>> In other words, the threat model is that the attacker sends commands with side effects that it shouldn't be able to, and doesn't care about reading the response.
> 
> This would rely on a WS server taking an undesirable side effect on
> the basis of a partially negotiated WS connection.
> If such a server was written, surely it would be vulnerable to any WS
> client and thus this is not a cross protocol issue, just
> a poorly written server.   More importantly, is there anything about a
> raw HTTP request that cannot be done in a normal WS upgrade request
> that is likely to trigger such a side effect?

The raw HTTP request can include a body, which is sent immediately, rather than waiting for the remainder of the handshake. The body can include content framed as WS protocol messages. A WebSocket client will wait until the handshake is complete. So yes, the possibility of attempting an HTTP connection to a WebSocket server does create additional attack surface.

> 
> 
>>> + The inability to send a pong frame
>> 
>> I don't think this one is true. Why couldn't you include it in an HTTP message body? Your original proposal does nothing to prevent this. Adding a server-provided nonce to the ping and requiring it to appear in some form in the pong does add some protection, but only as strong as the server's (possibly ad-hoc) choice of RNG.
> 
> It is conceivable that some HTTP requests might also be valid WS
> frames.   However, as HTTP sent from the server will start with
> HTTP/1.1 XXX reason, then only very contrived frames could be sent.
> The first two bytes of a ping frame carrying a 16 byte hash are STX
> DLE, and certainly not a valid HTTP response and an invalid method
> name in a HTTP request.
> 
> So I stand by my claim that a pong frame cannot be sent by a HTTP
> client, but perhaps some very contrived framed could be (see below).

You don't need the WebSocket frame to be a full HTTP message. You simply put as many WebSocket frames as you want in your HTTP body ahead of time. (That's the original threat model I suggested - you cue up an XHR that has a number of WebSocket frames in the body.) This is the reason client parts of the handshake need to not be predictable up front for an attacker.

> 
> 
> 
>>> + The inability to provide credentials (not otherwise available to
>>> normal HTTP) to access authorized content
>> 
>> Network position is itself effectively a credential. Some servers are only protected by a firewall. This is common not only in enterprise scenarios but also with many consumer devices that offer Web-based configuration. Browsers generally consider it their responsibility not to expand the attack surface in such cases.
> 
> If the network is the only credential needed, then the compromised
> browser will eventually have a WS client and thus this is not a cross
> protocol issue.     There is nothing about WS that is different than
> just HTTP in this regard and we would have to hope that the browser
> origin policy would protect both HTTP and WS from such poorly
> authenticated services being attacked by local compromised clients.
> Unfortunately many such environments probably have XSS vulnerabilities
> as well, so the origin model can be subverted, but this is an existing
> risk and there is no additional risk introduced by WS here.

WS is different for reasons stated under the first point. It won't send messages of the client's choice until the handshake is complete.

> 
> 
> 
>>> + The inability to make a WS server send unauthorized content as
>>> valid WS frames
>> 
>> Not relevant to the threat model. Again, because the threat is an attack on integrity, not confidentiality.
>>> + The inability to provide credentials (not otherwise available to
>>> normal HTTP) that might trigger server side effects
>> 
>> Not relevant to the threat model, which is existing HTTP functionality being used to attack WebSocket servers.
> 
> They are still defences against other cross protocol attacks, hence I
> listed should be listed as part of the defences.

OK, but not defenses against the particular threat I suggested.

> 
> 
> 
> 
>>> + The inability to send a WS frame from a HTTP client that might
>>> trigger server side effect.
>> 
>> I don't think this is true. What stops you from sending the bytes of a WS frame from an in-browser HTTP client?
> 
> It is indeed possible that some HTTP messages may indeed be valid WS
> frames, and I think that perhaps we
> need to do some further consideration of the framing mechanism to make
> sure that ASCII method names do not
> become legal frame headers.

You don't need to use a full HTTP message to send a WS frame, you can just put them in the body of a single message. That's what my original threat model imagined.

Using multiple HTTP requests in combination with HTTP pipelining is an interesting additional threat that I hadn't thought of.



> 
>>> + That even if all of the above could be subverted, the attacker
>>> would only have a capability (to talk WS), that we plan to have widely
>>> available within the browser.
>> 
>> WebSocket itself will not send any frames until the handshake is complete, but HTTP sends the body along with the headers. So it's not the same. You can't count on browser-side checking of the server response to protect WS servers from HTTP clients.
> 
> I don't think you have understood my point.   Let's say that we can
> subvert a HTTP client so that it passes the WS handshake, so we know
> have a WS connection wired to a HTTP client.   Does that now give us
> any capabilities that represent a threat that we would not have if we
> were using a WS client?

The HTTP client doesn't need to really pass the handshake - it just needs to do a good enough job to fool the server, long enough for the server to read some frames. If the server expects it will never even get client frames until the protocol is complete, it may be in for a bad surprise.

You could say it's just the server author's responsibility to code defensively, but I think it would be even better if the protocol is designed to make it hard to make implementation mistakes of this kind.

> 
> Actually to answer my own question, a HTTP message that is contrived
> to look like a WS frame will be able to have the opcode and RSV bits
> set by the caller, which otherwise is not the case for WS clients.  So
> this last defence is weaker than I represented, but that's why we have
> defence in depth.   Again, we might want to revisit framing to ensure
> that HTTP methods cannot form valid WS headers.
> 
> Excellent - this exchange has finally been productive and I think we
> have indeed identified some weaknesses (albeit already existing in
> -76) that may need to be strengthened if we suspect that a HTTP client
> could somehow get past the other handshake defences.
> 
> But so far, there has been no indication that my proposal to change
> the nonce encoding and to frame the hashes as WS packets has weakened
> the defences.  I believe that the analysis we are doing is still
> showing that it is at least as secure as -76.

I suspect -76 is not strong enough, but it is slightly stronger in some specific ways. First, by spreading the data across multiple header fields and incorporating whitespace, it makes it slightly trickier to do injection attacks. Second, by requiring the server to combine data from multiple places, it makes it more likely the server will read more of the handshake.


Another possible strengthening is to design the actual message framing such that it is affected by data from both the client and server parts of the handshake. Let's say the whole frame header is XOR'd with the sum of client and server nonces. Then it is impossible for the server to read frames produced by a party that didn't really participate in the handshake, and likewise makes it impossible to read frames without checking the handshake. Effectively this (lightly) encrypts frame headers so they look like random bytes if there wasn't a proper handshake. For bonus points encrypt the message bodies too, and this would shore up defense against attackers using WebSocket to talk to another protocol (since, past the handshake, their bytes would look random and not actually be controlled by them).

I don't know offhand what the perf impact would be of this kind of approach. 

I note that this ad-hoc approach starts to resemble TLS the more it has added to it, only without the years of review and deployment experience, which is why I am somewhat skeptical of heading further in this direction.


Regards,
Maciej