- From: Adam Barth <whatwg@adambarth.com>
- Date: Sat, 8 Aug 2009 22:46:31 -0700
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