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

Re: widget example of CORS and UMP

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 14 May 2010 02:53:37 +0000 (UTC)
To: Dirk Pranke <dpranke@chromium.org>
Cc: public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.64.1005140155390.12269@ps20323.dreamhostps.com>
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?

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

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

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 14 May 2010 02:54:11 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:25 UTC