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

[Bjoern Hoehrmann <[e-mail]>]

* Scott Ferguson wrote:
>IP restrictions aren't practical because clients access sites from a 
>variety of devices including mobile access points. A $2 a month server 
>on a shared virtual host certainly isn't doing authentication using IP 
>identification.
>
>You're now claiming:
>
>  1. DELETE public to the world
>  2. No credential-based authentication
>  3. Strong IP authentication which forbids the local host, but allows 
>arbitrary browser IPs.

The scenario is: there is a web server 1.2.3.4 that supports a.example
and b.example. The attacker controls a.example, and b.example e.g. does
not allow requests coming from anywhere but a certain IP address range.
A small business for instance may be hosting a collaboration platform on
a shared server, but the platform can only be accessed from their office
network. The platform may require additional authentication, but trying
to overcome those can be part of an attack. The Websocket frames just
need to look like HTTP so the server does not close the connection. The
exchange could go like this:

(Websocket handshake)
  C: WEBSOCKET ... HTTP/1.1
  C: Host: a.example
  C: ...

(Websocket handshake)
  S: HTTP/1.1 101 Switching Protocols
  S: ...

(First Websocket frame(s) just happen to look like HTTP)
  C: DELETE / HTTP/1.1
  C: Host: a.example
  C: Content-Length: ...
  C: ...

(Whatever response the attacker feels like sending)
  S: ...

(Websocket traffic, starting from a point chosen by the attacker)
  C: WHATEVER /anywhere HTTP/1.1
  C: Host: b.example
  C: ...

By choosing the Content-Length in the HTTP-spoofing first Websocket
frame carefully, what goes to b.example can come from the free-form
Websocket payload. The attacker just needs to make sure the browser
keeps the "Websocket" connection open and the HTTP server keeps the
"HTTP" connection open, at least long enough to do something meaning-
ful; the attacker can then re-establish the connection as needed.

Right now, to take the example above, if an attacker tricks someone
in the office network to visit a.example, the options for attacks on
b.example are rather limited, for instance, only a few method verbs
are available, the browser will send a Referer header, he can't read
out the responses, and so on. If the above works, the attacker has
more options.

Obviously there are a number of ways to make this kind of attack hard
or even impossible, I just wanted it to be clear that an attacker is
not able to simply use XMLHttpRequest or something similar instead and
do all the same things.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/