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

["Thomson, Martin" <[e-mail]>]

> > Invent a scenario for me.  How does this allow the attacker to gain
> the
> > nuclear launch codes?
> 
> There's no way to extract data in such a scenario, as far as I am
> aware,
> unless the subprotocol supports a way to trigger data to be sent out of
> band. To use your analogy, the risk is not getting nuclear launch
> codes,
> it's just launching the nukes.
> 
> Suppose an author wrote a Web Socket server that launches nukes upon
> request. The server is in on a secure intranet, and all users are
> trusted,
> so there's no authentication required. The server therefore can ignore
> the
> handshake, and just needs to scan for frames that have the request.
> 
> There's no way for an attacker on hostile.example.com to open a Web
> Socket
> connection to nukes.intranet.example, since the browser would read the
> handshake from nukes.intranet.example before allowing a frame to be
> sent,
> and the handshake says that only the origin nukes.intranet.example is
> allowed. However, hostile.example.com can instead do an XHR or form
> submission to nukes.intranet.example, with the payload being carefully
> crafted to contain just a frame causing a nuke. The server would
> receive
> it, ignore the (wrong) handshake, see the frame, and set off the nukes.
> A
> worker browsing the Web with a computer on that intranet who happens to
> go
> to hostile.example.com could, without their knowledge, fire the nukes.

Thank you.  I think that I understand your scenario a little better.

> 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 thing is, this sort of indication (i.e. that the server is a WS server) is made clearer by the presence of the "Upgrade: " header in the 101 response (or the presence of the response itself).

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.

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.

That requires a little too much suspension of disbelief for me.  Your proverbial server implementer will do whatever is necessary to get their app working.  I put it to you that they will pass your intelligence test, and fail in other more spectacular ways.  No matter how complicated you make the test.

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...)

> > If this is as simple as a programmer forgetting the distinction
> between
> > /Upgrade: foo/ and /^Upgrade: foo/, then we're back to disagreeing on
> > the same old and tired topic.
> 
> Yes. 

No comment.

--Martin