W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: widget example of CORS and UMP

From: Tyler Close <tyler.close@gmail.com>
Date: Fri, 14 May 2010 13:44:48 -0700
Message-ID: <AANLkTimUl5H53W23vNrwo35anKb2Q0frPEzynbJXylKT@mail.gmail.com>
To: Dirk Pranke <dpranke@chromium.org>
Cc: Maciej Stachowiak <mjs@apple.com>, public-webapps <public-webapps@w3.org>
On Fri, May 14, 2010 at 12:27 PM, Dirk Pranke <dpranke@chromium.org> wrote:
> 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".

Further down in this email, you punt on my example, saying that it
can't be deployed. If there are classes of applications that CORS
cannot address, and these classes are important, then there are "hard
unknowns" in CORS. For example, will the Security Considerations
section of CORS have to say:

"It is not safe in CORS to make a GET request for public data using a
URL obtained from a possibly malicious party. Validating the URL
requires global knowledge of all origins that might grant special
access to the requestor's origin, and so return private user data."

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

I saw him assert that. I didn't see him show that. What are the
pitfalls that have not been addressed in the UMP spec?

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

Or, a reasonable audit could say: "that's a fine app, so long as
you're using UMP". If CORS requires the app to be rejected, that's a
failure for CORS and this WG.

I see the WG's role here as defining a protocol that enables
applications. Saying "don't do that", as has become popular of late on
this list, is failure.

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

Do you realize the full extent of that decision? See the my first
comment in this reply about language for the CORS Security section.

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

Ok, fair enough. I thought you were repeating Ian's argument. If not
the same, what relationship between the two are you trying to
highlight with that statement?

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

UMP explicitly doesn't make any recommendation for where the secret
token should be put. It does provide some advice on where not to put
it. The permission token can be put in a POST body, if the developer
feels that's safer. We have a lot of experience doing that. The
security of the Web today mostly relies on this technique.

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

I don't think that statement applies to this case. I think cookies are
not a good defense, especially in multi-party scenarios. They have a
broken implementation (as Adam has shown) and create invalid
assumptions.

If the end result of this discussion is that CORS proponents say we
have to keep cookies just for defense in depth of an UMP style design,
then the CORS spec should explicitly say that and caution developers
against relying solely on cookies + Origin.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Friday, 14 May 2010 21:08:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT