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

[Greg Wilkins <[e-mail]>]

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.
 + Reliance on the browser not treating the 101 response as an error.
 + The inability to read the ping frame after the 101 response.
 + The inability to send a pong frame
 + The inability to provide credentials (not otherwise available to
normal HTTP) to access authorized content
 + The inability to make a WS server send unauthorized content as
valid WS frames
 + The inability to provide credentials (not otherwise available to
normal HTTP) that might trigger server side effects
 + The inability to send a WS frame from a HTTP client that might
trigger server side effect.
 + 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.


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