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

iframe sandbox suggestion

From: Artur Adib <arturadib@gmail.com>
Date: Thu, 1 Apr 2010 11:50:39 -0400
Message-ID: <t2kbfb5ebad1004010850mf58b084frd6caf62516f8c081@mail.gmail.com>
To: public-html-comments@w3.org
This is a suggestion concerning the HTML5 sandbox attribute of <iframe>.

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

Consider the case where a parent document from domain A.com embeds an
iframe from a third-party source, from domain B.com.  The parent page
at A.com might contain sensitive information in its location href
(think of GET requests), and a sandboxed B.com shouldn't be able to
read it.

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.

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.

Any thoughts?

-- 
Artur Adib
http://arturadib.blogspot.com
Received on Thursday, 1 April 2010 16:32:03 GMT

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