W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [UMP] Feedback on UMP from a quick read

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 8 Jan 2010 16:56:54 -0800
Message-ID: <7789133a1001081656w44cd596dwefca35fbde5530c0@mail.gmail.com>
To: Tyler Close <tyler.close@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
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

Received on Saturday, 9 January 2010 00:57:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:04 UTC