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

Re: CSP and cross-frame communication

From: David Bruant <bruant.d@gmail.com>
Date: Wed, 15 Feb 2012 20:20:50 +0100
Message-ID: <4F3C0592.1070000@gmail.com>
To: Jacob Rossi <Jacob.Rossi@microsoft.com>
CC: "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Le 15/02/2012 18:57, Jacob Rossi a écrit :
>>>    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.
Excellent.

What about local storage?
An instance of local storage is supposed to be bound to an origin. If 2
sandboxed frames have different origins, it means they can't share the
same local storage, even if they've been loaded from the same URL.
Moreover, it seems that hitting "refresh" on a web browser could
generate a new origin, making pointless the idea of "local storage"
(since you can't reaccess the values you stored, since your origin changed).
It seems to be how it should be, but the need for a client-side storage
remains.

Maybe the model for managing local storages should be reconsidered for
the case of unique-origin documents? I'll try to think of a proposal.

> I'm not sure what you mean transferring the origin.
I used the wrong word, sorry.
If I open an iframe and this iframe is loaded in a sandboxed manner
thanks to the sandbox directive, can the opener use its "access" to the
iframe to create resources of the same origin?
Can the opener use the unique origin without the iframe knowing? I can't
think of any, but I'm asking in case someone did.

>>>> 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.
So "sandbox" alone and giving a value to "script-src" would be an
invalid state.
Enforcing both should probably be defined by the spec or they should be
merged in a way so that there is no invalid state possible.

>> 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.
Indeed, there is a loophole. I'm not sure I understand the point of
preventing built-in mechanisms, but that's ok, if I still have a way to
re-enable them, I'm happy.

>> 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.
So, in a sandboxed document, one cannot create popups even if that's
what is wanted by scripts allowed by script-src.
I find that a bit restrictive: if I chose the scripts I want to allow, I
wish them to do what I intended, regardless of how stupid and annoying
to the user it might be.

As soon as I choose the scripts I trust with the directive, I don't see
a reason to restrict what this script can do. If I want to load other
scripts with restricted API, I can use my trusted scripts to load other
scripts through solutions like Caja.

Thanks for your response,

David
Received on Wednesday, 15 February 2012 19:21:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 February 2012 19:21:23 GMT