W3C home > Mailing lists > Public > public-web-security@w3.org > March 2011

Re: CSP interaction with about:blank and document.open

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 29 Mar 2011 18:23:22 -0700
Message-ID: <AANLkTi=wnGkVFSV9_FHhtym2rkQp8TbiLj8tCNrzYeF_@mail.gmail.com>
To: Brandon Sterne <bsterne@mozilla.com>
Cc: public-web-security@w3.org
On Tue, Mar 29, 2011 at 2:24 PM, Brandon Sterne <bsterne@mozilla.com> wrote:
> This was sure easier when we were just dealing with CSP-over-HTTP :-)
>
> On 03/24/2011 04:26 PM, Adam Barth wrote:
>> Sayeth CSP:
>>
>> [[
>> If a scheme is not specified as part of the source expression, a
>> user-agent MUST use the same scheme as the protected document.
>> ]]
>>
>> Which scheme, precisely, should we use?  For example, suppose we have
>> an about:blank document that (somehow) acquires a CSP policy.  Should
>> we use "about" as the default scheme?
>
> In Gecko, window.open()ed documents receive the principal, and thus
> location, of the opener.  You can verify this using the following test
> (which works in Firefox and Safari, but not Chrome for some reason):
>
> var w = window.open("about:blank");
> w.document.write("<scr"+"ipt>alert(location.href)</scr"+"ipt>");
>
> So it would follow that if a page calls window.open() and
> document.write()s some content and a CSP into the document, then the
> user agent would use the document principal to produce the default scheme.

Your test case isn't quite right.  Calling "write" on w.document is
what changes the URL.  Try setting document.documentElement.innerHTML
instead.  :)

>> Suppose we have an about:blank iframe inside a document with a CSP
>> policy.  Should the document inside the iframe be bound by the CSP
>> policy of the paper frame?  (Same question for data URLs.)
>
> I'm honestly not sure if the document inside the about:blank iframe
> should inherit the outer document's CSP, but one possible solution would
> be to say no and simply permit the container document to inject a policy
> as a <meta> element when it populates the iframe.  This would allow a
> site to implement either inherit or don't-inherit behavior for this type
> of dynamic iframe.

Ok.

>> Recommendation:
>>
>> 1) We should incorporate the CSP policy for a document into the
>> security origin state for the document, just as HTML5 does for
>> iframe@sandbox.  That means the CSP policy will inherit although with
>> the rest of the document's security context (e.g., origin and sandbox
>> flags).
>
> I don't know if we want this.  This would eliminate the ability of a CSP
> page to create an about:blank or data: iframe/window that doesn't share
> the same policy.

Right, is that a good thing or a bad thing?  That's the judgement call
we need to make.

> I don't know if that is a huge problem, but it does
> seem like one we could avoid by having user agents keep track of who
> opened each window and inheriting some data from the opener, but not
> necessarily the entire security context.

We already inherit the entire security context in those cases.

>> 2) We should grab the scheme from the origin of the document.
>
> I think you are using "origin" here as I was using "principal" above.

Principal is a Gecko concept.  Origin is an HTML5 spec concept.
They're pretty much equivalent.

>> If the
>> document has a security origin that lacks a scheme (e.g., because it's
>> been sandboxed), then we ignore source values without an explicit
>> scheme (aka, no soup for you).
>
> I totally agree with this.

Adam
Received on Wednesday, 30 March 2011 01:24:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 March 2011 01:24:26 GMT