- From: Tyler Close <tyler.close@gmail.com>
- Date: Sat, 9 Jan 2010 07:23:13 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps <public-webapps@w3.org>
On Fri, Jan 8, 2010 at 4:56 PM, Adam Barth <w3c@adambarth.com> wrote: > On Fri, Jan 8, 2010 at 4:43 PM, Tyler Close <tyler.close@gmail.com> wrote: >> On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth <w3c@adambarth.com> wrote: >>> [... Requiring uniform responses to redirects ...] >>>> It's a good thing to question, since this feature is a >>>> relaxation of the model, but it seems valuable and without risk. Can >>>> you think of a danger here? >>> >>> Here's an obscure risk: >>> >>> 1) An enterprise (example.com) has a partially open redirector >>> (go.corp.example.com) behind their firewall >>> 2) The redirector will only redirect to *.example.com >>> 3) There is a public site api.example.com that opts into UMP >>> >>> Now the attacker can probe go.corp.example.com by asking for redirects >>> to api.example.com and reading back the response. >> >> I actually considered that case and convinced myself that the attacker >> *could* mount the attack using a <form> or <iframe> by timing the >> request. A working redirect will likely take longer to return than a >> broken redirect. Also, the attack can work without timing, but using a >> <script> tag, if the response can be parsed as ECMAScript. >> >>> This is especially >>> problematic if the redirector attaches interesting bits to the URLs it >>> directs (like API keys). This attack is not possible with the <form> >>> element. >> >> Any unguessable bits in the redirect URL should not be revealed, since >> the attacker does not get access to the non-uniform redirect response, >> even if the final response is a uniform response. >> >> This design is also already dangerous, since using a <form> tag, the >> attacker can already freely exercise these API keys. > > You're assuming the API keys are for integrity. What if they're for > confidentiality? If the response can be parsed as ECMAScript, an attacker can break confidentiality by loading the document using a <script> tag. Also, for any media-type, the attacker can mount a clickjacking attack against this design. Since in general this design cannot be made safe, I think it's better to not support it at all in the security model, by allowing a uniform request to follow a non-uniform redirect. A security model that works for some media-types but not others is just too bizarre to explain to developers. This choice doesn't endanger existing resources, since CORS also allows a cross-origin request to follow a redirect that has not opted out of the Same Origin Policy. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Saturday, 9 January 2010 15:23:45 UTC