Re: websocket HTTP response parsing

Ian Hickson wrote:
> On Mon, 7 Jul 2008, Julian Reschke wrote:
>> "The requirement that the handshake not be one that an existing server 
>> can be tricked into sending".
> 
> One of the key aspects of this feature is that it not be abusable in the 
> sense of a hostile site connecting from the user's machine to services on 
> the internet or intranet that are not expecting machines under the control 
> of the author to connect to them.
> 
> For example, if a connection could be made from a Web page to an SMTP 
> server, then a hostile author could use this API to send spam.
> 
> Similarly, if a connection could be made to an HTTP server behind a 
> firewall, then a hostile author could obtain confidential data.
> 
> Or a hostile author could connect to an IRC server and cause the user's 
> machine to act as an IRC bot.
> 
> And so on.
> 
> The goal of the handshake is to make this impossible, by dropping the 
> connection if the remote host doesn't show a willingness to take part in 
> the Web Socket protocol, and a willingness to communicate with the page in 
> question, based on its origin (in the HTML5 sense).

OK, thanks for the explanation.

In this case I would advise to have that handshake *after* the websocket 
connection has been established (so in the case where this actually goes 
through a real HTTP server, *after* the 101 is returned). Keep in mind 
that there are other things that could go wrong, such as the server 
returning  the headers "Upgrade:" or "Connection:" in a different order, 
or interleaving them with other headers (such as "Date:").

>  ...

BR, Julian

Received on Monday, 7 July 2008 12:36:15 UTC