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

[Adam Barth <[e-mail]>]

On Sun, Sep 26, 2010 at 6:22 PM, Greg Wilkins <[e-mail]> wrote:
> 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:
>
> 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.

Browser also protect intranet servers which use connectivity as their
sole means of authentication/authorization.

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

The existing HTTP mechanisms exposed to untrusted content in browser
already respects these security invariants.  In adding new network
APIs, browser wish to continue to maintain these invariants.

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

Potentially, yes.  That's why we have to worry about these issues in
designing the handshake.

> ie are there any exploit HTTP requests that
> can be generated using the WS client that could not be generated
> anyway?

Not if we correctly secure the WS protocol handshake against these threats.

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

This is not an accurate understanding of the security invariants
browsers seek to maintain.

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

Browser seek to protect servers that have never heard of WebSockets
and have no interest in these newer technologies.  From that
perspective, it's important to compare the security invariants of the
browser before and after introducing WebSockets.  We need to study any
change in these invariants to make sure they don't introduce security
vulnerabilities in existing servers.  This is a prerequisite for
exposing the WebSocket API to untrusted content in the browser.

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

That's part of the question.

> I still think that we should take reasonable measures to prevent cross
> protocol handshakes - even if there are no identified real security
> issues.

Instead of playing "whack a mole" against the cross-protocol attacks
we can think of today, we should design the protocol such that we have
reasonable assurance that we won't discover cross-protocol attacks
tomorrow.  The WebSocket protocol is going to be with us for a long
time.  These attacks are subtle and take years to flush out of a
shoddy design.

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

With all due respect, I'm not convinced you have a strong enough
handle on the required security properties to make such a bold claim.

Adam