Re: [hybi] Websocket: two protocols into one, and Internet rules broken

[Ian Fette (イアンフェッティ) <[e-mail]>]

Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from
the handshake to prove that the remote end is indeed a websocket server as
you point out. The other part is that Sec-WebSocket-Accept takes the key
from the Sec-WebSocket-Key header, which XHR cannot send and thus the server
doesn't have the information necessary to generate the Accept value as there
is no key from the client.

The original question you link to is basically "why does the server have to
answer a challenge", and it breaks down into two parts:

1. Force server to validate that the client is a WebSocket client (by making
it use a value from Sec-WebSocket-Key along with the GUID, we ensure that
the server actually checks for the presence of Sec-WebSocket-Key.)
2. Let the client validate that the server is actually a WebSocket server
(by checking that Sec-WebSocket-Accept is properly computed).

#1 lets the server be sure it's not responding to some random XHR request,
#2 lets the browser know that it's safe to connect and that it's
communicating to a WebSocket server and not some non-WS target.

On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <[e-mail]> wrote:

> I started to try and answer this StackOverflow question about the protocol
> text and realized that I didn't understand it as well as I thought:
>
> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>
> The question is related to this paragraph (which has been in the drafts for
> a while unchanged):
>
>     Finally, the server has to prove to the client that it received the
>     client's WebSocket handshake, so that the server doesn't accept
>     connections that are not WebSocket connections.  This prevents an
>     attacker from tricking a WebSocket server by sending it carefully-
>     crafted packets using |XMLHttpRequest| or a |form| submission.
>
> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
> from being tricked into connecting to a non-WebSocket server. However, I'm
> having difficulty understanding how the Sec-WebSocket-Accept header would
> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
> sent from the server. I am aware of the prohibition against "Sec-" headers
> in the client to server direction. Is there a requirement that
> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
> user agents (and if so does this only apply in the browser case)?
>
> It's likely I just don't have enough context to understand the paragraph,
> but perhaps it could be clarified a bit.
>
> Regards,
>
> Joel Martin
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>