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

[Maciej Stachowiak <[e-mail]>]

On Sep 26, 2010, at 6:22 PM, Greg Wilkins 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:
> 
> 
> 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.

If you don't understand the risks, then I am not sure you are in a good position to propose solutions or evaluate their effectiveness. Please try to read up on cross-protocol attacks, a simple Google search and the paper that James Graham linked earlier in the thread are great starting points. Many in this WG seem to discount the importance of security risks that they do not personally understand. Well, trust me, the bad guys understand them, and they are not going to be dissuaded by the difficulty of these issues, nor will they give us an A for effort if we work very hard but still produce something insecure.

I will note in fairness that my original attacks were against the old (-75) handshake which did not have any kind of protection. I have also learned a lot more about cross-protocol attacks since originally posting the email I cited, which proposed a nonce with hash response as protection and nothing else. Largely thanks to pointers from and personal conversations with Adam Barth.

One thing I have learned is that it is very risky to have a defense that just barely works. These are very likely to become defenses that don't work at all in the face of a trickier attack, or a novel seemingly minor vulnerability that breaks the assumptions of the defense.

The reason I am skeptical of your proposed ping-poing handshake as a defense against cross-protocol attacks is that the *only* defense protecting WebSocket servers from attacks over HTTP is the assumed inability of browser-hosted HTTP clients to send whatever carries the random nonce, or something that looks sufficiently similar. Your summary doesn't specify exactly how the nonce is sent, but I'll assume it is using a header that normally cannot be sent via cross-site XHR or similar APIs.

Now, imagine that a Web attacker, using in-browser APIs, can send something that looks close enough to the nonce-carrying header to fool a server. This could be due to a client bug, or due sloppy server processing (e.g. parsing with regexps and not carefully checking for newlines), or due to a bug in an intermediary (tricked into injecting extra headers). At this point, the ping-poing exchange does nothing to protect the server for attacks. The attacker could have queued up a body that sends the pong plus any additional messages without needing to look at the ping, and the server will blindly process them.

Now, you could argue that such a scenario is merely a bug in either the client or the server or the intermediary, and the protocol is not at fault. But I would look at such a scenario and say the security of the protocol is extremely brittle. It would be better to have a protocol that is more robust in the face of buggy software.

A potential improvement would be to require the server to produce a random number, which is included in the ping and must be in the pong in addition to the hash. In that case, an attacker could not queue up the correct pong without looking at the server's response at all. But going down this road results in increasingly elaborate schemes, along the lines of the -76 handshake. It's also likely there are more complicated flaws that we simply haven't thought of yet. I don't think we can stake the security of this protocol just on our own ability to think up attacks within a period of only a few weeks.


As I have thought about these issues, I am increasingly convinced that an NPN-style solution is much more robust. Attempting to make a TLS connection to a vanilla HTTP server, or an HTTPS server that does not understand NPN, will reject the connection at a very low level, greatly limiting the potential for shenanigans. Browser clients in general do not offer APIs that would allow a Web attacker any control of the outgoing TLS handshake, and the TLS layer would fail a bad connection before server software even had the opportunity to make a mistake. This approach seems much more robust to me. Rather than just barely being secure, it fails hard before the attacker can even do anything tricky. I think it is much likely there would be future attacks. I hope the WG strongly considers the NPN approach, despite the costs and challenges imposed by using TLS.

Regards,
Maciej




> 
>> 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
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi