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

On Fri, Jan 8, 2010 at 3:56 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Fri, Jan 8, 2010 at 3:36 PM, Tyler Close <tyler.close@gmail.com> wrote:
>> There are two uses for this requirement:
>> 1. On browsers that don't yet support any cross-domain API, it would
>> be nice to emulate support by routing the request through the
>> requestor's Origin server. To help ensure the response is the same
>> whether it was sent directly from the user agent or via the Origin
>> server, we omit any information about the sending software.
>
> If this is an important consideration, then the server software can
> just copy the relevant headers.  I'm not sure there's a good security
> case to be made here for deviating from standard operating procedure.
> It seems quite sensible to send an Accept header of */* instead of
> omitting the header.

I'm not making a security argument here, just an engineering one. It
seems simpler and more efficient this way.

>> 2. Omitting these headers can significantly reduce message size and so
>> improve performance.
>
> This seems like premature optimization to me.  Do you have benchmarks
> that show this has any impact on page load time (or any other metric
> you think is interesting)?

Reading Steve Souders stuff has impressed upon me the cost of message
size overhead. If you just open up a Firebug console, it's clear that
these headers are eating up a significant fraction of the MTU and so
splitting messages that should've gone over the wire in a single
packet.

All that said, perhaps it makes more sense to move this recommendation
to individual UMP API specs, such as UniformRequest, rather than deal
with it in the UMP spec, leaving it as purely about the security
model. At the very least, that delays the controversy. I'll remove the
text from the UMP spec.

> [... 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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Saturday, 9 January 2010 00:44:11 UTC