[whatwg] Comments on @sandbox
ian at hixie.ch
Thu Nov 5 21:11:19 PST 2009
I'll respond in more depth later, but some quick notes since you're
reviewing a patch:
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.
It's actually more dangerous than you describe, because, per spec,
'allow-same-origin' only takes effect when the nested page is loaded,
whereas the allow-scripts value is live, so if it is set initially, then
removed (which has no effect) and replaced with 'allow-scripts' (which
does), the nested frame is same-origin with scripts enabled.
There's currently a red warning in the spec about this.
(We could resolve this by making 'allow-scripts' not be live.)
> I recommend letting servers deliver the sandbox policy both via the
> sandbox attribute and via an HTTP header. The value of the HTTP header
> approach is that the document will be sandboxed in whatever context the
> user agent loads the document. For various esoteric reasons, I wrote up
> a description of how this might work on Mozilla's Wiki:
I agree, but I didn't want to get ahead of ourselves -- in particular
given the work on CSP. We wouldn't want to end up with both. Also, some of
the requirements may be a little different (e.g. CSP probably wants to
disallow inline scripts but not external scripts, whereas here we're not
worried about XSS within the sandboxed frame, so it doesn't make much
sense to do that).
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg