W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: innerHTML in DocumentFragment

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 8 Nov 2011 17:10:08 -0800
Message-ID: <CANMdWTtv-z6yRKu11pmWzNK6=z+ck8LsbdHE10FBgxLGhJaaZw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Ryan Seddon <seddon.ryan@gmail.com>, Yehuda Katz <wycats@gmail.com>, public-webapps WG <public-webapps@w3.org>
Providing concise, easy and XSS safe ways to generate a DOM is certainly
something we have to solve. I don't think sandbox is the best way to
achieve this. Specifically, I don't believe sandbox on iframes actually
strips the script elements, does it? It just doesn't execute them.

If we want to continue down the string->DOM approach, then I agree with
Jonas, we need to define an algorithm for safe innerHTML and use it in all
the places where we can currently set HTML. I'm open to supporting this
use-case because the XHR pattern is so common.

The other solution being proposed for easy, safe DOM creation is
quasi-literals, which I believe we should definitely also do. In those
cases, you'd have something like:
var myDom = html'<a href="">foo</a>';

The browser would provide a built-in html function that returns a DOM and
uses the browser's html parser. These are not strings though, so you can't
use the response from an XHR here.

On Mon, Nov 7, 2011 at 8:36 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 7, 2011 at 8:23 PM, Ryan Seddon <seddon.ryan@gmail.com> wrote:
> > On Tue, Nov 8, 2011 at 4:30 AM, Ojan Vafai <ojan@chromium.org> wrote:
> >>
> >> I don't really follow. Script won't execute until you append the
> fragment
> >> to the DOM, at which point the fragment itself doesn't go in the DOM,
> just
> >> it's children. So, I'm not really sure what sandboxing on fragments
> would
> >> do.
> >
> > If I was ajaxing in potentially hostile content that had malicious script
> > tags in it it would be ideal to "sandbox" the content so the HTML parser
> in
> > the browser would strip the content for me.
> >
> > xhr.responseText = "<div><script
> > src="//malicious.site/cookieStealer.js"></script><h1>content</h1></div>";
> >
> > var frag =  document.createDocumentFragment();
> >
> > frag.sandbox = "";
> > frag.innerHTML = xhr.responseText; // it's sandboxed so the script(s)
> will
> > be stripped by the parser.
> >
> > document.body.appendChild(frag);
> >
> > The following article demonstrates the same concept using an iframe with
> the
> > sandbox attribute set[1]. This to me would also make sense to be
> extended to
> > fragments.
> >
> > [1]
> >
> http://community.jboss.org/people/wesleyhales/blog/2011/08/28/fixing-ajax-on-mobile-devices
>
> I do think we should add something like this, however I think we
> should have a more explicit syntax for it. There's an old thread with
> subject "innerStaticHTML" in the WHATWG list which discusses this
> topic and various possible syntaxes.
>
> Note that inserting a untrusted piece of HTML into your document is
> interesting not just when dealing with document fragments. Both
> div.innerHTML as well as div.insertAdjecentHTML(...) seems like they
> could use "safe" variants.
>
> In short, I think a separate thread is needed for this :)
>
> / Jonas
>
Received on Wednesday, 9 November 2011 01:10:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT