Re: [hybi] handshake security (was: Frame size)

[Ian Hickson <[e-mail]>]

On Mon, 19 Apr 2010, Thomson, Martin wrote:
> > 
> > The new handshake works around this (as described in the message 
> > above) by requiring that the server prove that it checked the 
> > handshake. In the scenario above, the server would fail to find the 
> > right information to create that proof; there is a much better chance 
> > that the author would then bail rather than continue trying to listen 
> > for further frames.
> 
> Post mortem detection of the problem doesn't solve anything.  If the 
> browser has sent the XHR blindly, the damage is done by the time that it 
> learns that the server is a dumb WS implementation.  You can't go and 
> stuff the missiles back in their silos.

The idea is not to make the client able to do anything, the idea is to 
make the server more likely to fail to get to the point where it is 
accepting frames without having checked that it's a Web Socket client.


> If the server only looks for certain markers, then I imagine that an 
> SMTP message could trigger launch in the same fashion.  It doesn't stop 
> the attack.

I don't see how you could cause any privileged machine in this scenario to 
connect to the Web Socket server using SMTP. Could you elaborate on that?


> What you are trying here is analogous to a qualification exam for server 
> implementers.  If they can pass this test, then you assume that they're 
> smart enough not to make other silly mistakes.

Not really. I have no doubt that most amateur programmers would have no 
more trouble with the handshake than anything else (it's pretty trivial, 
after all). However, to do the handshake correctly they need to collect 
the information. If they fail to collect the information, they can't send 
back the handshake. What I'm assuming is that if they can't send back the 
handshake, they won't just send back nothing and then look for frames. To 
help with this, in the case where they don't have the information, they'll 
likely also have to deal with a division by zero, which in many cases will 
effectively mean they ignore the frames (as their program will have 
crashed or at least failed in some non-trivial way).

It's naturally possible for a programmer to fail to collect all the 
information, catch the division by zero, and _still_ go out of their way 
to look for frames and thus be vulnerable. There's only so much we can do.


> That requires a little too much suspension of disbelief for me.

It would be good to test the protocol to find out how often it is 
correctly implemented. Once their are some browser implementations of this 
handshake, I would like to see how a group of programmers from various 
backgrounds who have not been participating in this working group manage; 
this would give us real world data pointing out problem areas, whether 
there are areas prone to security problem that we had not considered, etc.


> It's quite possible that any viable solution to that problem would be 
> more trouble than it's worth.  (you know, there might be a business in 
> that...)

Not sure what you mean.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'