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

RE: CSP and cross-frame communication

From: Hill, Brad <bhill@paypal-inc.com>
Date: Tue, 14 Feb 2012 23:01:12 +0000
To: David Bruant <bruant.d@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E02F144@DEN-EXDDA-S11.corp.ebay.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.

  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.  I believe this would achieve the effect you intend - if not, perhaps a counter-example would clarify things?


Brad Hill

> -----Original Message-----
> From: David Bruant [mailto:bruant.d@gmail.com]
> Sent: Friday, February 03, 2012 2:22 PM
> To: public-webappsec@w3.org
> Subject: CSP and cross-frame communication
> Hi,
> Before starting, I'd like to thank you for CSP and the script-src directive which
> I find pretty awesome. By design, it solves a ridiculous amount of problems
> and certainly allows some optimizations that weren't possible before
> (document.write in inline scripts may block HTML parsing, but this is not a
> problem when inline scripts are not allowed).
> But I would like to discuss about cross-frame communication and how CSP
> addresses it.
> I see that there is a "sandbox" directive in discussion, which is the equivalent
> of the @sandbox attribute of HTML5.
> By default, the behavior would be to prevent frames from executing scripts,
> sending forms, to navigate its parent or to allow the parent to consider the
> child frame as if it was of the same origin.
> None of these seems to address one source of complexity with iframes which
> is same-origin frames synchronous communication. Indeed, when 2 frames
> are of the same origin, each can mess up with the built-ins of the other
> (Object.prototype or document, for instance). This means that if one page
> gets hacked and is embedded as an iframe in other pages, these other pages
> are compromised as well.
> What about a directive (like "no-synchronous-cross-frame-communication")
> that would guarantee that in a given document, only the scripts in that
> document have synchronous access to this document resources (like
> ECMAScript built-ins)?
> Communication would then be only possible through
> postMessage/onmessage event from and to this document.
> On the positive side of things, it could allow browser vendors to further
> isolate frames regardless of their origin (when the directive is enabled, of
> course).
> Cheers,
> David
Received on Tuesday, 14 February 2012 23:01:44 UTC

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