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

[Philipp Serafin <[e-mail]>]

I think it would be useful to explicitly state the kinds of exploits
that could happen though.

So far, it looks that the only situation where a XMLHTTP-treated-as-WS
request could do harm were when it could access a normally
origin-protected resource from a foreign origin. (From what I
understand, the handshake doesn't protect against attacks on
intermediaries, that's the job of the masking).

However, to properly origin-protect a resource, the server already needs
to check the sec-websocket-origin header - so it is already forced to do
validation.
On the other hand, if the operators of the server don't bother with
origin checks and allow the resource to be accessed cross-origin I don't
see any additional security risks in (trying to) access the resource via
a very kludgy XMLHTTP request than via a WS connection.

I know this has probably been the most-discussed topic on this list and
it's not my intention to cause any additional eye rolling. I just think
it should be taken care to clarify the reasoning behind the handshake,
since this will probably a lot of discussion in web developer forums
once WS is up and running.

Regards,
Philipp Serafin

Am 16.06.2011 22:39, schrieb Ian Fette (イアンフェッティ):
> Historically, many servers are lazy. They will not bother validating
> whatever the client sends, and will just return some value and then
> get exploited. By forcing the server to prove something to the client,
> we essentially also force the server to validate at least part of the
> client's handshake (rather than just hardcoding in some 101 Upgrade WS
> response). So, by making the server prove something to the client,
> it's a way of forcing the server to actually take some steps that have
> a side effect of protecting it (e.g. this /forces/ the server to parse
> the Sec-WebSocket-Key header.)