W3C home > Mailing lists > Public > public-web-security@w3.org > January 2010

Re: Sandboxed iframes (was Re: Seamless iframes + CSS3 selectors = bad idea)

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 19 Jan 2010 23:12:16 -0800
Cc: "sird@rckc.at" <sird@rckc.at>, Adam Barth <w3c@adambarth.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, gaz Heyes <gazheyes@gmail.com>, public-web-security@w3.org
Message-id: <2A18C027-848A-48C6-B2C5-868A1AE97324@apple.com>
To: Ian Hickson <ian@hixie.ch>

On Jan 19, 2010, at 5:05 PM, Ian Hickson wrote:

> On Sun, 6 Dec 2009, Maciej Stachowiak wrote:
>> Taken literally this rule does not seem practically implementable. UAs 
>> would have change their JavaScript implementations to tag every 
>> JavaScript string value with an origin, to keep track of where it was 
>> found if it gets passed cross-origin (e.g. via postMessage). It's also 
>> possible for data: URLs not to be found in any script or document, if 
>> they are created by script in appending multiple strings or taking user 
>> input.
>> What Firefox seems to do is give a data: URL frame the same origin as 
>> the frame that initiated navigating it to that data: URL. That seems 
>> like a secure and implementable rule.
> I've tried to fix the spec to be saner here.

> On Mon, 7 Dec 2009, Maciej Stachowiak wrote:
>> I think it would need to introduce a notion of the origin that initiated 
>> a load or navigation to get this right. I think that may also be 
>> necessary for javascript: URIs - the way javascript: URI handling is 
>> spec'd right now is kind of vague on the origin details.
> What case is vague?
> On Mon, 7 Dec 2009, Maciej Stachowiak wrote:
>> Actually, using the same algorithm WebKit uses for "about:blank" *would* 
>> be universal XSS, since "about:blank" is same-origin with the parent or 
>> opener regardless of who initiated the navigation. (The reason this is 
>> safe for about:blank but not for data: URLs is that the attacker cannot 
>> put arbitrary contents in an about:blank frame).
>> Our handling of javascript: URLs is a bit closer to what is desired, in 
>> that we won't execute javascript: URLs at all cross-origin. However, 
>> this is done by preventing them from being sent cross-origin in the 
>> first place. I believe this also violates HTML5 as written - HTML5 seems 
>> to require executing such JavaScript URLs in an empty environment and 
>> using their string (although the wording there seems kind of vague).
> That section is certainly not my best work in terms of readability, but I 
> do believe it is strictly fully defined. What are the cases that are 
> vague? I hesitate to change anything in this section.

I don't remember what exactly I thought was vague when I wrote these two comments, but if I see problems when I review the new spec text I will file bugs with the details.

Received on Wednesday, 20 January 2010 07:12:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:17 UTC