W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2010

[whatwg] Comments on @sandbox

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 12 Jan 2010 08:16:36 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.1001120256530.8484@hixie.dreamhostps.com>
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.


Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 12 January 2010 00:16:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC