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

[Mike Belshe <[e-mail]>]

On Sun, Sep 26, 2010 at 9:35 PM, Maciej Stachowiak <[e-mail]> wrote:

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

+1.  If we think WebSockets has to solve these security problems, the best
bet is TLS.

Further, if we're going to take the expense of a round trip in the
handshake, we might as well get TLS, not just a nonce-verification.

Mike


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