Re: widget example of CORS and UMP

On Fri, May 14, 2010 at 11:27 AM, Dirk Pranke <dpranke@chromium.org> wrote:
> On Fri, May 14, 2010 at 10:18 AM, Tyler Close <tyler.close@gmail.com> wrote:
>> On Fri, May 14, 2010 at 1:15 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> OK, so there's two vulnerability scenarios:
>>
>> Actually, there is at least one other kind of vulnerability in the
>> CORS design that has not been mentioned by anyone yet and that does
>> not require XSS or untrusted code.
>>
>> Before I describe the attack, I want to remind everyone that the
>> purpose of this particular scenario was to study the usability of CORS
>> and UMP in a benign situation. This example only has a page from Yahoo
>> talking to servers also operated by Yahoo. There are also no
>> side-effects in this example; it's purely a data presentation example.
>> Given that CORS and UMP are new protocols and that this is the most
>> benign scenario we can conjure, I think it's fair to expect a solution
>> with strong security properties. It should be damning if the solution
>> to this very simple scenario introduces complex security problems.
>>
>
> We are talking about enabling a class of functionality (cross-origin
> messaging) that isn't currently possible on the web. Obviously if it is
> possible to do so securely and easily, that's a good thing. If that is not
> possible, and the options are to enable things that have relative degrees
> of security or ease of use, then it becomes much more debatable.
> "Damning" is a strong word to use in this situation,

If the introduced security problems are complex and therefore hard or
infeasible to solve, then "damning" is the right word. If the simple,
benign scenario is made infeasible, that's damning.

>  especially since I
> think most people would see the interchange between Maciej and I that
> neither solution (CORS or UMP) makes things trivially securable. Another
> conclusion could be that doing this stuff is just hard.

There's a big difference between "trivially" and infeasible. What are
the issues with UMP where we cannot provide concrete guidance to
developers? As I've shown, there are hard unknowns in the CORS
solution.

>> If the Yahoo Finance portfolio was designed to use UMP instead of
>> CORS, this hack would not compromise any private
>> portfolio data since the attacker doesn't know the unguessable secret
>> for anyone's private portfolio.
>>
>
> If the code had been audited, then it is reasonable to assume that someone
> would have caught that allowing the HotTrades service to tell the user to
> fetch *any url at all* was a bad idea, and the API should have been
> restricted to "GET http://finance.yahoo.com/stock/%s/instaprice" instead
> of "GET %s".

You've changed the scenario so that now HotTrades can only happen on
Yahoo listed securities, instead of those listed on any exchange in
the world. You have to allow fetching of any URL to make the
application work. A possible CORS solution is to check that the URL
does not refer back to a user private resource on my.yahoo.com and so
do a check on the domain in the URL from HotTrades. However, now you
have to wonder about other domains that accept cross-domain requests
from my.yahoo.com, such as finance.yahoo.com. How do you list all
other domains that might be giving special cross-domain access to
my.yahoo.com? You can't; it's an unbounded list that is not even under
the control of my.yahoo.com.

> This is also what Maciej said in his Don't Be a Deputy
> Slides - "Guarantee that requests on behalf of a third party look different than
> your own".

How do I make a GET request for public data look different? I look
forward to seeing DBAD explained in greater depth. I am completely
unconvinced by what has been presented to date.

> You are correct that it is possible to use CORS unsafely. It is possible to use
> UMP unsafely,

Again, that is broken logic. It is possible to write unsafe code in
C++, but it is also possible to write unsafe code in Java, so there's
no security difference between the two languages. Please, this
illogical argument needs to die.

> since - as others have expressed - everything depends on the URL
> being unguessable.

or putting an unguessable token somewhere else in the request.

In CORS, everything depends on the cookie being unguessable and
confidential. Adam has shown how hard that is.

> Many people seem to feel that this is at least as
> great a flaw
> as the ambient authority flaw.

As you and Maciej discussed, a truly secure solution requires the use
of unguessable secrets outside of cookies. Whether you argue for CORS
or UMP, you must have techniques for protecting these non-cookie
secrets.

> So, to me, your argument suggests that we either should not implement
> either solution,
> which no one will find acceptable, or we should implement a solution
> that requires
> *both* unguessable tokens and cookies.

I don't follow your logic here. We have techniques for protecting
unguessable tokens outside of cookies. We know that cookies *don't*
provide a good way to protect unguessable tokens. Adam has clearly
shown that.

--Tyler

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

Received on Friday, 14 May 2010 19:01:15 UTC