On Sat, Aug 8, 2009 at 10:46 PM, Adam Barth <span dir="ltr"><<a href="mailto:whatwg@adambarth.com">whatwg@adambarth.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In IRC, Ian asked me to investigate a security issue involving<br>
redirects and the websocket protocol. In particular, he's worried<br>
about the following scenario:<br>
<br>
1) A trustworthy web site, <a href="http://example.com" target="_blank">example.com</a>, wants to send the string<br>
"DELETE" over a web socket an malicious server, <a href="http://attacker.com" target="_blank">attacker.com</a>.<br>
2) A victim server behind a firewall, <a href="http://corp.victim.com" target="_blank">corp.victim.com</a>, deletes an item<br>
specified by a path when it receives the string "DELETE" over a web<br>
socket that:<br>
A) comes from a trusted IP address (e.g., one behind the firewall) and<br>
B) implicates a trust-worthy origin in the Origin header (e.g., example).<br>
<br>
The attack proceeds as follows:<br>
<br>
1) A user behind the firewall visits <a href="http://example.com" target="_blank">example.com</a>.<br>
2) <a href="http://example.com" target="_blank">example.com</a> attempts to establish a websocket with <a href="http://attacker.com" target="_blank">attacker.com</a>.<br>
3) <a href="http://attacker.com" target="_blank">attacker.com</a> redirects the socket to <a href="http://corp.victim.com" target="_blank">corp.victim.com</a>.<br>
4) <a href="http://example.com" target="_blank">example.com</a> sends the string "DELETE" to <a href="http://corp.victim.com" target="_blank">corp.victim.com</a>.<br>
5) <a href="http://corp.victim.com" target="_blank">corp.victim.com</a> delete a file of the attacker's choice.<br>
<br>
In fact, the situation is worse than the above because the websocket<br>
protocol supports cookies. Instead of relying on a firewall and IP<br>
authentication, the victim server could be on the public Internet and<br>
be relying upon cookie authentication.<br>
<br>
I think there are a number of ways of resolving this issue:<br>
<br>
1) We could use Sec-From instead of Origin because Sec-From implicates<br>
the full redirect chain instead of just the origin that initiated the<br>
request. On IRC, Ian said he doesn't like this choice because servers<br>
might not validate this header properly.<br>
<br>
2) Instead of handling the redirect inside the websocket protocol, we<br>
can report the redirect back to the web site making the request (in<br>
this case <a href="http://example.com" target="_blank">example.com</a>). Then the trustworthy web site would then have<br>
the option of following or not following the redirect. If we did<br>
this, we would have to ensure that the redirecting server understands<br>
the websocket protocol (probably by requiring it to send<br>
WebSocket-Origin or some such) to avoid leaking the targets of<br>
already-existing redirects. Also, it's unclear on what basis the web<br>
site would decide whether to follow the redirect.<br>
<br>
3) We could restrict redirects to the same origin. This has the<br>
disadvantage of not covering the full use case of redirects.<br>
<br>
4) We could remove support for redirects.<br></blockquote><div><br></div><div>#4. I feel like redirects add unnecessary complexity.</div><div><br></div><div>We're already asking application developers to handle ACKing, keep alives, multi-plexing, connection limiting, authentication, etc themselves. To me, it doesn't seem like much of an additional burden to ask them to handle redirects. And by keeping the spec simple, I think we'll increase the chances of quick adoption by UAs, which will speed up the adoption by web apps, which will give us feedback on what features web developers actually want much quicker.</div>
<div><br></div><div>J</div></div>