Re: widget example of CORS and UMP

On Fri, May 14, 2010 at 12:00 PM, Tyler Close <tyler.close@gmail.com> wrote:
> 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.

You've shown that there are cases where CORS is not secure. I don't know that
I would agree with your assessment that you've shown that there are
"hard unknowns".

As Maciej has shown, simply saying "make sure the URL can't be easily
obtained" is not
that easy.

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

If that is true, then a reasonable audit would not allow that app to run on
my.yahoo.com, because of the dangers involved.

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

If it is not possible to deploy an app with the level of distinction
possible, then
you don't deploy it.

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

I did not say that they were the same.

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

True, and yet people use it all the time to provide a "good enough" level of
security. Despite the fact that we have 12+ years of people attacking it really
hard. We don't have anything like that kind of experience protecting unguessable
URLs (or implementing them on a widespread basis), so don't claim that we
know the risks remotely comparably.

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

Yes, but we also protect the cookies. Attacks against one defense
don't necessarily
defeat the other as well. Do you agree that two good-but-not-perfect defenses
are better than one good-but-not-perfect defense?

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

Hopefully my comments above make that clearer.

-- Dirk

Received on Friday, 14 May 2010 19:27:40 UTC