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

[Maciej Stachowiak <[e-mail]>]

On Sep 28, 2010, at 2:36 AM, Greg Wilkins wrote:

> Maciej,
> 
> taking our offline conversation back to the list (as you suggested), you said:
> 
>> I don't think you identified any effective defenses other than inability
>> to send the intended form of the nonce (as a Sec- header).
>> 
>> I would be glad to elaborate further on the list if that would be helpful.
> 
> 
> I believe that more defences have been discussed than just the
> inability to send the nonce. Specifically the following defences have
> been identified (but perhaps not enumerated as thoroughly):
> 
> For a HTTP client to attack a WS server, the defences are:
> + The inability to send a nonce in a Sec-Header.

Agree on this one.

> + 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.


> + 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.

> + 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.

There are ways to send other credentials in cross-site requests, for example by doing it through a form instead of XHR. I haven't thought through those cases in detail yet so I don't have a strong claim to make at this time.

> + 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.

> + 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?

> + 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.


The risk I described did not fall into the three other threat models below, so no comment on those for now. I will review the list later, time permitting.

Regards,
Maciej

> 
> 
> For a WS client to attack a HTTP server:
> + The inability to force intermediaries and servers to generate a 101 response
> + The inability to force a server to emit a ping frame after a 101 response
> + The inability to know what contents to put into a ping frame even
> if one could be injected.
> + The inability to provide credentials (not otherwise available to
> normal HTTP) to access authorized content
> + The inability for the server to send unauthorized content in a WS frame.
> + The inability to provide credentials not available to via a normal
> HTTP request that might trigger some authorized side effect.
> + The inability to send valid HTTP requests from a WS client.
> + If all of the above could be subverted, then the existing browser
> cross domain model could be broken and an attacker could view content
> from a different domain. But if the server was injectable to such an
> extent as to allow 101s and ping frames, then it is highly likely that
> javascript code could be injected that would also break the cross
> domain model without the use of WS.
> 
> 
> For a WS client to some other protocol server:
> + The browser restricts the port range that can be the target of a WS
> connection
> + Reliance on the server to not treat the HTTP handshake request as a
> fatal error.
> + The inability to force the servers to generate a 101 response
> + The inability to force a server to emit a ping frame after a 101 response
> + The inability to know what contents to put into a ping frame even
> if one could be injected.
> + The inability to force another protocol server to send unauthorized
> content in a websocket frame.
> + The inability to provide credentials not available to via a normal
> HTTP request that might trigger some authorized side effect.
> 
> 
> For a WS client to attack a WS server:
> + The inability to force a server to send arbitrary origin headers,
> so attacking code will not be from the same origin as the connection.
> 
> Note that these defences are essentially identical between -02 and my
> proposal - ie they are not dependant on space encoding of nonces nor
> the unframed transmission of nonces and hashes.
> 
> I'm not saying these defences are perfect, nor that they cannot be
> improved. However I think that there are sufficient defences in depth
> (except for WS to WS) that they cannot be simply dismissed without
> some thorough detailed explanation.
> 
> regards
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi