Re: widget example of CORS and UMP

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

I should have mentioned that, as many others have pointed out, simply running
the widget off-origin (or in a sandboxed iframe) would also work. I do not agree
with your second sentence. We know the circumstances that make cookie-based
solutions dangers; you yourself have been very helpful in pointing them out.

So, I don't think your "hard unknown" characterization is accurate.

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

Yes, one would imagine saying something quite similar to that.

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

Well, he didn't show that any more than I showed how to get the unguessable
URL in the first place. However, the fact that he caught errors in my
description
of what you had to protect against seemed like a strong argument.

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

Hardly. No one said that enabling such an app under all the conditions
you enumerated was a requirement.

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

One could just as easily argue that UMP disallows you from using
user-friendly URLs, and that that is a 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.

Yes, of course.

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

I am attempting to highlight that neither solution is a panacea, and
that you need to be aware of the limitations of either approach. The
UMP "Security Considerations" section has a long list of SHOULDs that
need to be followed in order for the approach to be secure, just as
the HTTP-State draft does, and just as the CORS spec should.

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

The fact that UMP doesn't specify how to make something safe isn't
exactly an argument for it being easy to use correctly.

"The security of the Web today mostly relies on this technique" is a
difficult statement to prove or disprove. It is certainly true that
lots of confidential information is displayed on pages protected
solely by cookies, which is a counterclaim.

As I said earlier, clearly you disagree with others' opinions over how
easy it is to secure URLs. I am not sure that it is possible to
resolve this disagreement through words rather than deeds (meaning,
the best indicator of truth would be to deploy a bunch of UMP-based
solutions and show that they remain secure).

As an example, in an earlier job at a different company, I worked on a
service that included purchase/checkout flows and the ability to view
previous orders. The security team made it a requirement that all that
data needed to be protected by both unguessable tokens and cookies,
and I can tell you from experience that ensuring that the tokens
propagated through every navigation and hyperlink correctly was a
nontrivial exercise.

It is possible that there are web development tools that make this
easier (perhaps Waterken is one, although I have no direct experience
with it), but the vast majority of tools, languages, and frameworks do
not make this anywhere as close to as easy to do as it is to use
cookies.

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

Given that CORS was shown to safely enable a useful class of two-party
communication that is not currently possible today, we wouldn't be
likely to keep cookies "just for defense in depth".

It is certainly a fair requirement to "caution developers against
relying solely on cookies + Origin" in many scenarios; I think you
have well and thoroughly established that point.

-- Dirk

Received on Friday, 14 May 2010 22:53:55 UTC