- From: Dirk Pranke <dpranke@chromium.org>
- Date: Fri, 14 May 2010 10:17:20 -0700
- 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 UTC