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

[Greg Wilkins <[e-mail]>]

2010/9/27 Maciej Stachowiak <[e-mail]>:
> Here is an email from February where I summarized some of the risks from
> cross-protocol attacks for WebSocket:


Maciej,

thanks for the reference, but I didn't and still don't fully
understand the actual risk posed by those descriptions and that we are
still shadow boxing against perceived rather than real threats.

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

I don't understand "unauthorized access" in this context.   If a
server, HTTP or otherwise want to protect it's content, then it needs
to have both authentication and authorization, which typically means
that the client will possess some credentials that the server must
check.     If the server does not protect its resources or the
attacker already has access to credentials (or can trick the
browser/user into providing credentials), then the easiest way to
access a non-websocket server would be with existing HTTP mechanisms
in the browser.

Is there anything about WS that would make a vulnerable HTTP server
easier to exploit than just using the existing HTTP mechanisms
available in the browser? ie are there any exploit HTTP requests that
can be generated using the WS client that could not be generated
anyway?



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


I think that any server that "performs any side effects in response to
messages from the client" will have a security vulnerability if they
do not correctly check the authentication and authorization of the
client. Eventually most browsers will have WS available to the
javascript, so a server that is so vulnerable will be able to be
exploited just with WS instead of trying to trick HTTP.

The read question should be - are there any WS
authentication/authorization mechanisms that can be subverted by using
a HTTP mechanism instead of a the WS API?


I still think that we should take reasonable measures to prevent cross
protocol handshakes - even if there are no identified real security
issues.  But I think that the usage of Sec- headers and a simple nonce
will give very good protection and that we only need do more if there
is a real clearly identified risk.

regards