W3C home > Mailing lists > Public > public-html-comments@w3.org > April 2010

RE: iframe sandbox suggestion

From: Arthur Clifford <art@artspad.net>
Date: Thu, 1 Apr 2010 16:33:12 -0700
To: "'Ian Hickson'" <ian@hixie.ch>, "'Artur Adib'" <arturadib@gmail.com>
Cc: <public-html-comments@w3.org>
Message-ID: <01ab01cad1f3$b295cba0$0e14a8c0@iMacPCVirtualMachine>
What about providing an attribute for frames/iframes that told the user
agent to treat the framed content like its own window where top refer's to
the frames url not the top document's url. You could also specify that user
agents include a header of something like "Window-context: frame" on get
requests from framed content. That way server-side scripts could detect
inclusion in frames and react as appropriate.

Flash/Flex has similar issues where you can have flash content within flash,
but a flash developer (for the embedded movie) might refer to "root"
(roughly equivalent to top) and that messes things up in an embedded
context. So, there's a property that can be used to tell the Flash player to
treat requests for root in embedded context as root for the embedded movie
not root for the outer (top) flash movie.

So, generally:
 * Embedded/framed content needs to be flagged as embedded content
 * Embedded/framed content needs to be treated as if it were not embedded.
 * Embedded/framed content creators should be able to prevent their content
from being embedded by having access to some indicator that the content was
embedded.

Art

-----Original Message-----
From: public-html-comments-request@w3.org
[mailto:public-html-comments-request@w3.org] On Behalf Of Ian Hickson
Sent: Thursday, April 01, 2010 2:04 PM
To: Artur Adib
Cc: public-html-comments@w3.org
Subject: Re: iframe sandbox suggestion

On Thu, 1 Apr 2010, Artur Adib wrote:
> 
> I am concerned that the suggested implementation of the feature still 
> leaves a security hole, namely allowing a cross-domain iframe'd document 
> to *read* the window.top location. (I understand the current draft 
> forbids *navigation* at the top level, but it seemingly leaves the 
> possibility of *reading* the top level location).

Any cross-origin access to window.top.location's value is blocked:

 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#sec
urity-location


> A face-value solution is to raise a security exception when a 
> cross-domain, sandboxed iframe tries to read its top-level location. 
> However, this raises some compatibility issues with existing websites 
> that implement the so-called "frame buster" trick (see e.g. twitter.com, 
> nytimes.com), since these sites test whether top.location != 
> self.location to enforce they are not framed.

That wouldn't break because that doesn't compare the URLs, it compares the 
actual objects. Such a test would actually frame-bust even if the two 
objects were the same URL, assuming they were nested in each other.


> I believe a better solution (and one that incidentally puts an end to 
> the ridiculous "frame buster" war, see e.g. 
> http://en.wikipedia.org/wiki/Framekiller) is to return the sandboxed 
> location itself when it attempts to read top.location.  That way, the 
> sandboxed environment behaves as a standalone "mini-browser", without 
> any awareness concerning its surrounding environment.

Frame busting is necessary for security -- without it you are vulnerable 
to clickjacking. There is work ongoing to make frame busting work better 
(and not rely on script), but that wouldn't prevent these from working.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 1 April 2010 23:31:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:01 GMT