Re: widget example of CORS and UMP

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

> First I'll explain a concrete attack against the concrete example, and
> then I'll generalize it to explain why we should expect this problem
> to be recurring.
>
> The CORS solution to the scenario creates a widely known URL,
> "http://finance.yahoo.com/api/v1/my_portfolio", that is treated
> specially when the request happens to come from the my.yahoo.com
> origin. If you have tunnel vision on only the portfolio widget, then
> you might see no problem, but there are also other pages with other
> content on the my.yahoo.com domain. What happens if they make a
> request to this same URL, could something unexpected and wrong happen?
>
> Let's say myYahoo also has a page that fetches the "HotTrade of the
> Day" and posts its current price to my public activity
> stream, letting my friends know what investment I'm researching at the
> moment. The code for this content is audited by Yahoo and is not
> malicious.

> The "HotTrade of the day" can be on any market in the world
> and for anything. It might be hog futures in China or rice in Chicago.
> The page is used by momentum traders who just want to invest in
> anything
> that's moving quickly. Since no site lists the price of everything
> that can be traded, HotStocks returns the URL to GET the current
> price. The page content was created by a trading firm that wants to
> boost trades and attract new customers interested in trading on all of
> the world's markets.
>
> The page content makes the following requests:
>
> GET http://hottrades.foo/hotnow HTTP/1.0
> Origin: my.yahoo.com
>
> HTTP/1.0 200 OK
> Content-Type: text/plain
>
> http://finance.yahoo.com/stock/goog/instaprice
>
> and then:
>
> GET http://finance.yahoo.com/stock/goog/instaprice HTTP/1.0
> Origin: my.yahoo.com
>
> HTTP/1.0 200 OK
> Content-Type: text/plain
>
> 510.88
>
> and then:
>
> POST http://my.yahoo.com/stream/append HTTP/1.0
> Origin: my.yahoo.com
> Content-Type: text/plain
>
> I got my tip at 510.88. Find your price at:
> http://finance.yahoo.com/stock/goog/instaprice
>
> HTTP/1.0 204 OK
>
> Later, an attacker causes an unexpected URL to get into the HotTrades
> tip stream, resulting in the my.yahoo.com page doing the following:
>
> GET http://hottrades.foo/hotnow HTTP/1.0
> Origin: my.yahoo.com
>
> HTTP/1.0 200 OK
> Content-Type: text/plain
>
> http://finance.yahoo.com/api/v1/portfolio/mine
>
> and then:
>
> GET http://finance.yahoo.com/api/v1/portfolio/mine HTTP/1.0
> Origin: my.yahoo.com
>
> HTTP/1.0 200 OK
> Content-Type: application/json
>
> { /* all my portfolio data */ }
>
> and then:
>
> POST http://my.yahoo.com/stream/append HTTP/1.0
> Origin: my.yahoo.com
> Content-Type: text/plain
>
> I got my tip at { /* all my portfolio data */ }. Find your price at:
> http://finance.yahoo.com/api/v1/portfolio/mine
>
> HTTP/1.0 204 OK
>
> 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". 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".

You are correct that it is possible to use CORS unsafely. It is possible to use
UMP unsafely, since - as others have expressed - everything depends on the URL
being unguessable. Many people seem to feel that this is at least as
great a flaw
as the ambient authority flaw.

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.

-- Dirk

Received on Friday, 14 May 2010 18:28:14 UTC