W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2012

RE: CSP and cross-frame communication

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Wed, 15 Feb 2012 17:57:53 +0000
To: David Bruant <bruant.d@gmail.com>, "Hill, Brad" <bhill@paypal-inc.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <D0BC8E77E79D9846B61A2432D1BA4EAE0381627F@TK5EX14MBXC287.redmond.corp.microsoft.com>
>>    It sounds like what you're asking for is a way to prohibit cross-frame interactions that would normally be allowed by the Same Origin Policy, except through structured channels like postMessage.
>It is :-)

>>    One of the major aspects of the sandbox directive (should it eventually be supported in CSP) is that a sandboxed resource is forced into a unique origin.
> Is it unique per URL? For instance, if I open an iframe of the exact same URL as the opening page, will both have the same origin? My wish would be that no.
> Can this unique origin be "tranfered" in some way?

It's unique per frame/document.  So in the case that 2 frames have the same URL, they are treated as different origins and cannot access each other.  I'm not sure what you mean transferring the origin.

>>> I believe this would achieve the effect you intend - if not, perhaps a counter-example would clarify things?
>> I had missed the "unique origin" part of sandboxes, so I need to study more the implication of this, but it seems to achieve what I need indeed (assuming answers from above questions are satisfying). Thanks for pointing it out.

> However, it raises some questions.
> The sandbox attribute (and I'm assuming the sandbox directive as well) defines an "allow-scripts" keyword.
> What are the interactions between the different values of "allow-scripts" and the values of the "script-src" directive.

With "sandbox" alone, no script can execute. With "allow-scripts",  any script can execute *pursuant to the restrictions implied by "script-src"*.  So, script-src lets you further filter the scripts you've allowed to run in sandboxed content.

> About the sandbox attribute, HTML Standard mentions: "the 'allow-forms' 
> and 'allow-scripts' keywords re-enable forms and scripts respectively (though scripts are still prevented from creating popups)."
Allow-scripts does not re-enable form submission.  From the HTML5 spec, " The sandboxed forms browsing context flag, unless the sandbox attribute's value, when split on spaces, is found to have the allow-forms keyword set. This flag blocks form submission."

Following the "blocks form submission" link, it describes form submission both from clicking a submit button and also from invoking submit().

The only loophole here (AFAIK) is that you could read the values of a form and build your own form submission via XHR or something.  But built-in mechanisms for form submission are disabled.

> How does this "prevent creating popup" interacts with the script-src directive?
Not sure what you are asking. "prevent creating popup" means that popup APIs, such as window.open()/showModalDialog/etc. or links that target a new window, fail.
Received on Wednesday, 15 February 2012 17:58:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:26 UTC