[whatwg] Sandboxing ideas
gerv at mozilla.org
Thu May 10 06:09:03 PDT 2007
Ian Hickson wrote:
> Now we could exand that
> by putting, e.g., a hash into the <sandbox> element's attributes:
> <p>Hello, you said:
> <sandbox md5="e59ff97941044f85df5297e1c302d260">Hello World</sandbox>
> ...but that doesn't actually help us determine where the end should be.
If attributes on closing tags were allowed, you could do:
<sandbox secret="09f9...">Hello World</sandbox secret="09F9...">
In other words, make them match. So any inserted </sandbox> tags
wouldn't close the sandbox unless they knew the secret - which they
couldn't do, because they have the chicken-and-egg problem of having to
be able to read the page first.
> In fact I cannot see _any_ solution to the problem of allowing safe and
> server-side-free inclusion of arbitrary text in the body of an HTML page
> that doesn't have obvious attacks or limitations.
Other than the above, neither can I.
> The sanest way I can see of limiting scripting is to give it its own
> browsing context (aka scripting context, or global scope). Anything short
> of this would make the security model overly complicated -- the security
> model is what we want to keep at its simplest, as I've said several times
> in this e-mail.
I agree 100%.
> This basically implies an <iframe>, again possibly with the data in a
> data: URI, and combined with a way to ioslate the content in the <iframe>
> from the content of the parent browsing context:
http://www.gerv.net/security/content-restrictions/ , specifically the
"hierarchy" restriction, allows the <iframe> content to be isolated from
You also need <iframe>s which resize to content; that's
IE has the proprietary "security" attribute on <iframe> which restricts
script in various ways:
More information about the whatwg