On Thu, 5 Nov 2009, Adam Barth wrote: > > One interesting feature of @sandbox is that the hosting page can change > the value of the sandbox attribute. Even though it's clear that having > both allow-same-origin and allow-script at the *same* time lets the > sandboxed content escape, it's probably less clear to folks that first > setting allow-same-origin and then removing it and adding allow-script > is also very dangerous. > > The reason is slightly subtle. Essentially, when the frame is in the > allow-same-origin mode, it is very easy for the outer document to leak a > JavaScript object into the DOM of the inner document. Then, when the > frame enters the allow-script phase, the document can abuse the leaked > object to XSS the outer page, as described in > http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf>. > > The reverse sequence is also dangerous because the inner page could use > the techniques in this paper > <http://www.adambarth.com/papers/2009/adida-barth-jackson.pdf> to build > a fake DOM during the allow-scripts phase and confuse the outer page > into XSSing itself in the allow-same-origin phase. > > To avoid these subtle traps for developers, I recommend to freezing the > privileges of a sandboxed document at the time the document is loaded > into the frame.
Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
