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

Re: CSP and cross-frame communication

From: David Bruant <bruant.d@gmail.com>
Date: Thu, 01 Mar 2012 14:29:11 +0100
Message-ID: <4F4F79A7.9060902@gmail.com>
To: Adam Barth <w3c@adambarth.com>
CC: Daniel Veditz <dveditz@mozilla.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Le 01/03/2012 10:13, Adam Barth a écrit :
> I'm just saying that I don't know of a way to implement what you propose.
Ok, sorry for the misinterpretation.

> If you're interested, you should try hacking up a copy of Firefox or 
> WebKit to build a prototype of your idea.
It would take me a year probably since I haven't done C++ in years, 
don't have experience with C++ IDEs and tools and worse, no experience 
in what the WebKit or Firefox codebase look like for the DOM and network 
parts (I have just read some part of Spidermonkey).

I'll try to describe what my idea is about and explain why I think it's 

When a document is delivered with the 
"no-cross-frame-synchronous-communication" (the name can be changed, of 
course ;-)) directive, then:
1) If the document has been opened as an iframe by another frame, when 
the parent tries to access the contentWindow and contentDocument, these 
properties act as if the document was of a different origin (throwing 
error on access). I said "as if". I do not mean that the origin of the 
document should be changed.
2) When the document opens iframes, the documents can't access their 
parent as if the parent was of a different origin. (once again, I wrote 
"as if". The actual origin remains) Specifically, the parent, top and 
opener properties (and others if relevant) return null (I think it's the 
default behavior for cross-orign iframes)

The combination of both makes the document isolated from any synchronous 
cross-frame attack.

I think that 1 is feasible because it's about forwarding the directive 
and applying the cross-origin rules when it comes to cross-frame 
communication. A priori no need for new code, it's "just configuration" 
so to say. Applying the cross-origin behavior if the context is different.
I think that 2 is feasible for the exact same reason.

 From a functional point of view, what I have described sounds easier 
than the @sandbox attribute. I would assume it's consequently easier to 

Does what I have described sounds possible?

Received on Thursday, 1 March 2012 13:30:09 UTC

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