- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 6 Nov 2009 05:11:19 +0000 (UTC)
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: > <https://wiki.mozilla.org/Security/CSP/Sandbox>. 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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 5 November 2009 21:11:19 UTC