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

CSP and cross-frame communication

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 03 Feb 2012 23:22:27 +0100
Message-ID: <4F2C5E23.8080803@gmail.com>
To: public-webappsec@w3.org

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

Received on Friday, 3 February 2012 22:22:57 UTC

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