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

Re: widget example of CORS and UMP

From: Dirk Pranke <dpranke@chromium.org>
Date: Fri, 14 May 2010 10:17:20 -0700
Message-ID: <AANLkTim785V2OYD7FsHcporuuh2mT_BFO-xGHd1cARzQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps <public-webapps@w3.org>
On Thu, May 13, 2010 at 7:53 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 13 May 2010, Dirk Pranke wrote:
>>
>> The initial, insecure CORS solution is straightforward ... a "gadget"
>> running on My Yahoo! sends an XHR with the users' credentials to
>> "http://finance.yahoo.com/api/v1/my_portfolio" and gets some JSON back.
>
> If I understand this right, you are saying that the user visits
> my.yahoo.com, and that page does an XHR to finance.yahoo.com, right?
>

Yes.

>
>> One interesting aspect of the CORS solution is that there is no way for
>> the CORS-based gadget to get another user's data; it is simply not
>> possible to request it, since a different set of cookies cannot be
>> included in the request.
>>
>> The CORS solution requires you to believe in the security of proper
>> cookie handling. With an HttpOnly cookie, cookies can be handled pretty
>> safely but I imagine all of us are fairly aware that cookies get exposed
>> all the time and hence this is hardly a "perfect" solution, maybe just
>> "good enough".
>>
>> One could also observe that with the naive implementation of the CORS
>> API, *any* site could trivially fetch the user's portfolio data, which
>> is presumably not desirable, and so Yahoo! Finance would also need to
>> check the Origin: header.
>
> Actually it just needs to send back a header saying that only my.yahoo.com
> is allowed to read it, and the client will take care of it.
>

True, with a trusted client (which is generally what we're assuming).
And an untrusted
client could of course forge the Origin header.

>
>> Now suppose that My Yahoo! allows the user to install third-party
>> gadgets. Suddenly neither Yahoo! Finance nor the browser can distinguish
>> a safe request from a trusted gadget from an unsafe request from an
>> untrusted gadget.
>
> If my.yahoo.com is running _untrusted_ script in the context of
> my.yahoo.com, then forget XHR -- the game is already over long before we
> get to CORS. For example, the script could do a convincing phishing
> attack trivially, get the user's credentials, and then send them to the
> attacker for use offline. UMP or CORS are irrelevant here.
>
> If you want to run untrusted script, you can use <iframe sandbox>, and
> then CORS is neutralised (since the Origin is unguessable and unforgable),
> which seems to me to be what we want in that scenario.
>

True.

-- Dirk
Received on Friday, 14 May 2010 17:18:17 GMT

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