- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 25 Jan 2010 17:53:35 -0600
- To: Gavin Carothers <gavin@carothers.name>
- Cc: HTMLwg <public-html@w3.org>
On Mon, Jan 25, 2010 at 5:45 PM, Gavin Carothers <gavin@carothers.name> wrote: > Question for browser implementers: > > Currently sandbox is tied to iframe in the spec, is that strictly > necessary? Would it be possible to implement @sandbox in such a way > that it could be used on a div/article/p? > > eg: > <div sandbox="allow-same-origin"> > <p>javascript:x = 3; (x > 5)? "x is less": "x is greater"<br> > should be:<br> > javascript:x = 3; (x > 5)? "x is greater" : "x is less"<br> > </p> > </div> And if the content you're inserting is "</div><script>scaryXSSAttack();</script>"? It's more difficult to handle escaping properly with that solution, because you have to escape all unmatched </div>s (but only the unmatched ones - you want to allow "<div></div>" in your content). Hopefully you're using an element without automatic closing rules, too, or else you're in for even more fun trying to figure out what you need to escape and where. In general, it's too difficult of a problem to leave to authors. > >From an authoring/publishing perspective it would be MUCH simpler to > use and deploy. The fall back story is also much better, as older > browsers would still see the content (yes, that's a feature, not a > bug). If something needed to be more heavily sandboxed (only shown if > sandboxed) the iframe model would still work. Older browsers seeing the content un-sandboxed is most certainly a bug - it directly exposes them to any and all attacks in the content. Security is unlike other matters. You really *do* want to be conservative with it, and only accept things that conform precisely to what you expect. It's very important to preserve the same level of protection across all browsers, even if that means that legacy browsers fail entirely and don't show the content. Anything else is an attack vector. ~TJ
Received on Monday, 25 January 2010 23:54:27 UTC