W3C home > Mailing lists > Public > www-style@w3.org > February 2008

RE: Seamless transclusion of complex replaced elements

From: Justin Rogers <justrog@microsoft.com>
Date: Wed, 20 Feb 2008 10:40:58 -0800
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Brad Kemper <brkemper@comcast.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <00BD06E707F60B4F9D6A3E75C712209D49F11A39D2@NA-EXMSG-C104.redmond.corp.microsoft.com>

Though I can't review the bug at this time, Boris does sum up the general security principle below. This is further exacerbated by the fact that disallowing basic access to the iframe is not enough. The iframe, if it auto-sizes to content, could change the layout of the parent document and the layout changes being detected in the malicious document could be enough to then imply information about the iframe and allow information disclosure. This is the case of a malicious page hosting a vulnerable page in an iframe (there are other scenarios, but far more obscure).

Justin Rogers [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Boris Zbarsky
Sent: Wednesday, February 20, 2008 8:15 AM
To: Brad Kemper
Cc: www-style@w3.org
Subject: Re: Seamless transclusion of complex replaced elements

Brad Kemper wrote:
> Couldn't that be solved by not giving the document in the IFRAME
> JavaScript access to things like the document's or body's
> clientHeight, offsetHeight, scrollTop, scrollHeight, etc.

It's the other way around.  A document including a document from a different
domain in an iframe (or object, or whatever) must not be able to extract any
information from that child document.  That includes information like "preferred

That's discussed at length in the Mozilla bug I linked to, for what it's worth.

Received on Wednesday, 20 February 2008 18:41:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:34 UTC