Re: widget example of CORS and UMP

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.

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.

The fundamental problem with the CORS design is that it attaches
ambient permission to a well-known URL, the portfolio URL, so code
that thinks it is just fetching public data might inadvertently fetch
private data and reveal it. What URLs refer to private data versus
public data is unknowable by the web content. Any content that fetches
public data and then publishes a report on it could fall victim to
this kind of attack in a CORS world. For example, earlier Nathan was
interested in building a client-side web app that fetched Semantic Web
data from a variety of sources, computed on it and produced a result.
This app could very easily fall victim to this kind of Confused Deputy
attack in a CORS world. How is the app to know which URLs it accesses
have ambient permission attached to them that results in private data
being returned? In an UMP world, the app can fetch data without
attaching any credentials, so knows that anything that comes back must
not be user private data.

Considered only in isolation, the CORS solution might seem simple and
secure[1]. When you consider the effect this code has on the rest of
the origin and all the other code running on that origin, it clearly
not secure. How is every piece of code in the origin supposed to know
what ambient permission URLs have been made accessible to the whole
origin, and so might be unsafe to use. This is a recipe for a
hairball.

Given these Confused Deputy problems and the problems with cookies
that Adam points out in his IETF draft, the responsible decision is to
leave cookies and other ambient authority out of CORS, at least until
the underlying cookie mechanism has been made safe *and* we have safe
usage patterns to recommend to CORS application developers. Given that
there is also no implementation experience of using CORS with
credentials to build applications, these features are also entirely
speculative. The responsible decision here is obvious.

--Tyler

[1]  I dispute even that, since Adam has shown how unreliable cookies
are. One draft of the cookie spec even recommended against using
cookies in any new application. I recommend everyone read the Security
Considerations section of Adam's cookie draft
<http://tools.ietf.org/html/draft-ietf-httpstate-cookie-08#section-8>.

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

Received on Friday, 14 May 2010 17:18:39 UTC