Re: [hybi] Handshake was: The WebSocket protocol issues.

[Adam Barth <[e-mail]>]

On Mon, Oct 11, 2010 at 9:56 AM, Scott Ferguson <[e-mail]> wrote:
> Your attack assumes a needle in a haystack on the part of the attacker. Not
> only must the attacker add a site to the target's own web server,

This is not as hard as you might think:

http://people.csail.mit.edu/tromer/papers/cloudsec.pdf (see Section 7).

> he must
> hijack one of the target's own browsers while they're in the office which is
> a tiny universe of browsers.

This is also not that hard.  When thinking about browser security, we
usually give this to the attacker for free.

> Adam insisted on a non-upgraded HTTP server. Until he drops that
> requirement, you can't change the attack to an upgraded WebSocket-aware
> server.

This requirement isn't going anywhere.  I was surprised that it's not
in the requirements document.  It should be.

>> If it allows it for some then the
>> protection is meaningless, as the WEBSOCKET request goes to the attacker
>> (and similarily on point 6, the DELETE request goes to the attacker).
>
> You didn't address point #6, the open DELETE.
>
> The target is pre-compromised because it has an open DELETE (point #6) and
> the target is pre-compromised because it's on the same machine as the
> attacker (point #1).
>
> You're requiring a pre-compromised target to make this attack work.

I'm not sure what pre-compromised means.  I'm not sure that I'd run my
servers in this configuration, but that doesn't mean lots of other
people don't.

>> I do not quite understand point 4, but
>
> The point of #4 is that the universe of potential targets is restricted to
> those who don't care about security. Any site can have its own web server
> for $11/month, eliminating this attack entirely. No site seriously concerned
> with security would use a shared machine configuration because it's
> basically pre-compromised.

Well, we're interested in protecting the little guy too.

> In particular this restricts #3, the universe of browsers the target could
> hijack, because a small site with no security considerations is a tiny
> office with few target browsers.

Getting targeted folks to visit your web site isn't really that hard.
In fact, there's an entire industry devoted to exactly that:
advertising.  Failing that, targeted spam campaigns can also be very
effect.

By in any case, these are just the usual threat environment we work
with.  It's like asking how the attacker got a ciphertext/plaintext
pair to analyze when thinking about the security of a block cipher.

Adam