Re: [whatwg/dom] Declarative Shadow DOM (#831)

> 1. Use a browser **that supports declarative Shadow DOM**.
> 2. Use a client-side sanitizer that uses the **browser's HTML parser** to convert dirty HTML into an isolated `DocumentFragment`, e.g. by using `DOMParser`.
> 3. The sanitizer walks the resulting tree, pruning any malicious nodes.
> 4. The sanitizer returns **the DOM tree itself** to the user.
> 
> The sanitizer bypass HTML in this case would consist of a closed declarative shadow root containing the XSS payload. At step #2, the browser will parse the HTML into a DOM tree containing a closed shadow root, which contains the XSS payload. Step #3 cannot see this part of the tree, because of the definition of "closed shadow root". Step #4 therefore returns a DOM tree with the XSS payload.

Oh, I see. That would be indeed problematic. We probably need to make DOMParser and other DOM API to parse HTML not handle declarative Shadow DOM by default.

However, the sanitizer scenario that I had concerned been concerned was mainly ones that parse HTML in the server side and strips away any scripting content. Such a sanitizer would see the markup for `<template shadowroot>` as well as its content yet it won't know that this template element's content won't be inert. For that case, using `<shadowroot>` instead is an effective mitigation strategy because such a server-side parser would treat it as like any other element of known name.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-716262761