[whatwg] Redirects and draft-hixie-thewebsocketprotocol

In IRC, Ian asked me to investigate a security issue involving
redirects and the websocket protocol.  In particular, he's worried
about the following scenario:

1) A trustworthy web site, example.com, wants to send the string
"DELETE" over a web socket an malicious server, attacker.com.
2) A victim server behind a firewall, corp.victim.com, deletes an item
specified by a path when it receives the string "DELETE" over a web
socket that:
  A) comes from a trusted IP address (e.g., one behind the firewall) and
  B) implicates a trust-worthy origin in the Origin header (e.g., example).

The attack proceeds as follows:

1) A user behind the firewall visits example.com.
2) example.com attempts to establish a websocket with attacker.com.
3) attacker.com redirects the socket to corp.victim.com.
4) example.com sends the string "DELETE" to corp.victim.com.
5) corp.victim.com delete a file of the attacker's choice.

In fact, the situation is worse than the above because the websocket
protocol supports cookies.  Instead of relying on a firewall and IP
authentication, the victim server could be on the public Internet and
be relying upon cookie authentication.

I think there are a number of ways of resolving this issue:

1) We could use Sec-From instead of Origin because Sec-From implicates
the full redirect chain instead of just the origin that initiated the
request.  On IRC, Ian said he doesn't like this choice because servers
might not validate this header properly.

2) Instead of handling the redirect inside the websocket protocol, we
can report the redirect back to the web site making the request (in
this case example.com).  Then the trustworthy web site would then have
the option of following or not following the redirect.  If we did
this, we would have to ensure that the redirecting server understands
the websocket protocol (probably by requiring it to send
WebSocket-Origin or some such) to avoid leaking the targets of
already-existing redirects.  Also, it's unclear on what basis the web
site would decide whether to follow the redirect.

3) We could restrict redirects to the same origin.  This has the
disadvantage of not covering the full use case of redirects.

4) We could remove support for redirects.

I'll let you know if I come up with any better solutions.

Adam

Received on Saturday, 8 August 2009 22:46:31 UTC