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

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