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

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.

Regards,
Maciej