- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 21 Dec 2009 14:27:20 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps <public-webapps@w3.org>
On Mon, Dec 21, 2009 at 2:16 PM, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 21 Dec 2009, Tyler Close wrote: >> On Thu, Dec 17, 2009 at 5:49 PM, Ian Hickson <ian@hixie.ch> wrote: >> > On Thu, 17 Dec 2009, Tyler Close wrote: >> >> >> >> Starting from the X-FRAME-OPTIONS proposal, say the response header >> >> also applies to all embedding that the page renderer does. So it also >> >> covers <img>, <video>, etc. In addition to the current values, the >> >> header can also list hostname patterns that may embed the content. So, >> >> in your case: >> >> >> >> X-FRAME-OPTIONS: *.example.com >> >> Access-Control-Allow-Origin: * >> >> >> >> Which means anyone can access this content, but sites outside >> >> *.example.com should host their own copy, rather than framing or >> >> otherwise directly embedding my copy. >> > >> > Why is this better than: >> > >> > Access-Control-Allow-Origin: *.example.com >> >> X-FRAME-OPTIONS is a rendering instruction and >> Access-Control-Allow-Origin is part of an access-control mechanism. >> Combining the two in the way you propose creates an access-control >> mechanism that is inherently vulnerable to CSRF-like attacks, because >> it determines read access to bits based on the identity of the >> requestor. >> >> Using your example, assume an XML resource sitting on an intranet >> server at resources.example.com. The author of this resource is trying >> to restrict access to the XML data to only other intranet resources >> hosted at *.example.com. The author believes this can be accomplished >> by simply setting the Access-Control-Allow-Origin header as you've >> show above, but that's not strictly true. Every page hosted on >> *.example.com is now a potential target for a CSRF-like attack that >> reveals the secret data. For example, consider a page at >> victim.example.com that uses a third party storage service. To copy >> data, the page does a GET on the location of the existing data, >> followed by a POST to another location with the data to be copied. If >> the storage service says the location of the existing data is the URL >> for the secret XML data (http://resources.example.com/...), then the >> victim page suffers a CSRF-like attack that exposes the secret data. >> The victim page may know nothing of the existence or purpose of the >> secret XML resource. >> >> To avoid this pitfall, we instead design the access-control mechanism >> to not create these traps. With the bogus technique removed, the >> author of a protected resource can now choose amongst techniques that >> actually work. >> >> To address your bandwidth stealing concerns, and other similar issues, >> we define X-FRAME-OPTIONS so that a resource author can inform the >> browser's renderer of these preferences. So your XBL resource can >> declare that it was only expecting to be applied to another resource >> from *.example.com. The browser can detect this misconfiguration and >> raise an error notification. >> >> By separating the two mechanisms, we make the access-control model >> clear and correct, while still providing the rendering control you >> desired. > > I don't understand the difference between "<opaque string> <origin> > <opaque string>" and "<opaque string> <origin>". > > With XBL in particular, what we need is something that decides whether a > page can access the DOM of the XBL file or not, on a per-origin basis. > Whether the magic string is: > > X-FRAME-OPTIONS: *.example.com > Access-Control-Allow-Origin: * > > ...or: > > X-FRAME-OPTIONS: *.example.com > > ...or: > > Access-Control-Allow-Origin: *.example.com > > ...or: > > X: *.example.com > > ...or some other sequence of bytes doesn't seem to make any difference to > any actual concrete security. There's only one mechanism here. Either > access is granted to that origin, or it isn't. No, there is a difference in access-control between the two designs. In the two header design: 1) An XHR GET of the XBL file data by example.org *is* allowed. 2) An <xbl> import of the XBL data by example.org triggers a rendering error. In the one header design: 1) An XHR GET of the XBL file data by example.org is *not* allowed. 2) An <xbl> import of the XBL data by example.org triggers a rendering error. Under the two header design, everyone has read access to the raw bits of the XBL file. The one header design makes an empty promise to protect read access to the XBL file. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Monday, 21 December 2009 22:27:52 UTC