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: Sat, 25 Feb 2012 21:44:25 +0100
Message-ID: <4F494829.2020501@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 20:20, David Bruant a écrit :
> 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.
It seems that it was in the design of @sandbox to prevent access to the
local storage [1]:
"What privileges? Well, by default, “sandboxed” iframes can not
(...)
read or write cookies, local storage, or local SQL databases"

I think that this is annoying. I understand the necessity of isolating
the scripts running in a frame from scripts running in other frames, but
I don't see why this would be done at the cost of features (especially
local storage which has no replacement)

There is no word on how script-enabled sandboxed iframes interacts with
the local storage. I'll try to test that when I find time.

Overall, I think that the sandbox directive is too coarsed grained.
I wish to be able to declare a frame as being isolated from any other
frame regardless of their origin, but it shouldn't cost features.


Also, if someone really wants a sandboxed page, why not serve the
document as html-sandboxed? I mean add support for this content-type at
the browser level (as opposed to only iframe level)

> 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.
This sandbox issue got me thinking about local storage a lot. Just for
information, I have a draft of a local storage that would be free from
origin concerns. I'll try to write it up and post it to public-webapps
when I can.

David

[1] http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox
Received on Saturday, 25 February 2012 20:44:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 25 February 2012 20:44:57 GMT