- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 01 Mar 2012 14:29:11 +0100
- 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 feasible. 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 implement. Does what I have described sounds possible? David
Received on Thursday, 1 March 2012 13:30:09 UTC