[whatwg] The <iframe> element and sandboxing ideas

James Ide ide at berkeley.edu
Tue Jul 22 23:23:31 PDT 2008

On Tue, Jul 22, 2008 at 3:22 PM, Frode Børli <frode at seria.no> wrote:

> The server must escape all user generated content by replacing < with
> < etc. This is perfectly secure for all existing browsers. The
> sandbox instructs the browser to unescape. Completely fail safe for
> all.

Thanks for the clarification. As mentioned previously by other poster, I
think this could work iff UAs can be passed a set of safe tags, attributes,
and whatnot (i.e., a whitelist), defaulting to the empty set if no such set
is specified. UAs can then unescape permitted elements, filter out
disallowed attributes, and then handle the code as normal.

Perhaps the whitelist could be specified in a format akin to CSS. For
<span sandbox=1 whitelist="elements: a, em; attributes: href, lang, rel;
style-properties: color, font-weight"> ... </span>
For larger or often-used whitelists, a URL could be specified as in: <span
sandbox=1 whitelist="http://example.com/whitelist">, which would permit the
whitelist to be cached or used in multiple places in a document.

One design flaw of this whitelist format that comes to mind is that all the
specified attributes are allowed for all the specified elements. For
example, it is not possible to allow the "lang" attribute for only the "a"
element but not an "em" element in the same sandbox; i.e. the whitelist
"elements: a, em; attributes: href, lang" permits both <a lang="en"> and <em
lang="en">. On a side note, although the whitelist would permit <em
href="">, it would be treated as invalid HTML of course.


- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080722/49e77c1c/attachment-0001.htm>

More information about the whatwg mailing list