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

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

From: Brandon Sterne <bsterne@mozilla.com>
Date: Tue, 29 Mar 2011 14:24:49 -0700
Message-ID: <4D924E21.7020000@mozilla.com>
To: Adam Barth <w3c@adambarth.com>
CC: public-web-security@w3.org
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");

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.

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

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

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

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


> Thoughts?
> Adam
Received on Tuesday, 29 March 2011 21:22:42 UTC

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