Why does the server in a websocket request have to answer a challenge?

I'm reading the websocket specification and it says:

Finally, the server has to prove to the client that it received the client's WebSocket handshake, so that the server doesn't accep开发者_运维知识库t 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've read it several times, but it's still not clear to me as to why this is necessary.

---

The challenge-response mechanism forces the server to make sure that the client is a legit WebSocket client, and not a script doing funny stuff.

The challenge is sent in a "Sec-WebSocket-Key" HTTP header. Since browsers make sure that scripts cannot set "Sec-*" headers, this prevents a script from opening a WebSocket connection through an XMLHttpRequest.

If the server did not have to answer the challenge, it is possible that some lazy servers would ignore the "Sec-WebSocket-*" headers completely, leaving clients unprotected from rogue scripts.

It may also be a way of allowing the client to verify that it is talking to a WebSocket server, but I think that is not the main reason, since the server has to send a 101 Switching Protocols status code anyway, along with an "Upgrade: websocket" header.

---

What i think this is trying to prevent is two things.

1. Replay attacks where a man in the middle captures the packets and tries to re send them to the server as the server will ask a different challenge and thus reject the connection

2. Http post and xmlhttp requests sending data in such a way that it starts a web socket. The fact that these two methods cant reply means that the challenge goes un answered and the socket is rejected by the server

---

I was starting to answer your question and realized I didn't understand the paragraph as well as I thought so I've asked for clarification on the HyBi working group list. I'll update when/if I get an answer.

---

I would assume one major reason is to prevent attacks on servers if a websocket script was embedded in a popular website, for example. You could turn your entire userbase into an unwilling botnet.

This of course doesn't prevent a malicious person from doing it to an open websocket server, at least I don't think, but it would stop attacks on non-websocket servers.