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

> It's become clear that there are actually _two_ separate XSS issues under discussion. Let's consider the two security issues separately. There's what I'd call the "client-side XSS" (CSX) and the "server-side XSS" (SSX).

@dfabulich thank you very much for the clearly written summary of the problem(s) here!

> > I completely understand the concern about XSS issues. But blocking an entire feature (or otherwise making it much less usable, e.g. by adding HTTP header [footguns](https://github.com/whatwg/dom/issues/831#issuecomment-716078525), or disallowing `innerHTML` usage) based on this concern doesn't seem to make sense to me.
> 
> Designing new feature to be secure by default is [pretty important](https://w3ctag.github.io/ethical-web-principles/#privacy) [design principle we have](https://www.w3.org/TR/html-design-principles/#secure-by-design).

As I said, I understand the security concerns here, and I take them seriously. Implying otherwise is counterproductive here, I think. The problem I'm having at this point is data. The problems we're discussing are currently **hypothetical anecdotes**. They **very well might be real**, but it would be good to gather some data, so that we also [avoid needless complexity](https://www.w3.org/TR/html-design-principles/#avoid-needless-complexity). @rniwa do you have any **data** pointing to this being a real problem, not just a hypothetical?

For the server-side XSS (SXX) issue, the type of server we're looking for here is:
 1. Uses a server-side HTML sanitizer.
 2. Configures the sanitizer to **pass through** all children, **unsanitized**, of `<template>` nodes that it finds in the HTML.
 3. Does UA-sniffing of some kind, and **does it correctly**.
 4. For UAs that do **not** support the `<template>` element, the server does **not** do <span>#</span>2. For these legacy UAs, the sanitizer **does still send** the `<template>` element, but also sanitizes the contents of the `<template>` **correctly**.
 5. Receives a non-trivial (0.001% of page loads) amount of web traffic.

For the client-side XSS (CSX) issue, the type of setup we're looking for here is:
 1. Site uses a client-side sanitizer.
 2. The sanitizer uses the browser's parser, e.g. through `DOMParser` or `innerHTML`, to convert the HTML to (dirty) DOM.
 3. The **sanitizer supports**, and the **site configures**, the return of sanitized DOM nodes instead of sanitized HTML.
 4. Either the sanitizer is no longer being maintained, or the client site is not updating their sanitizer version to the latest.
 5. The site receives a non-trivial (0.001% of page loads) amount of web traffic.

For the SXX issue, @rniwa, any suggestions for how to go about gathering data here? Based on purely the conditions required for this, my assumption is currently that there is no non-trivial usage that meet all the conditions. But perhaps you know of some class of sites that we could investigate further?

For the CSX issue, since this is client-side code, I'm happy to do some HTTPArchive work to gather data. But @cure53, would you mind helping me out by giving me some pointers to DOMPurify's competitors? I just need a list of sanitizers that still have any significant usage on the web.



> 
> > Browsers add new XSS vulnerabilities all the time - they're called "bugs".
> 
> Like @koto says, I suspect you're conflating UXSS and XSS. We certainly don't introduce new APIs that cause existing sites to have a brand new XSS vulnerabilities all the time. In fact, we work hard to avoid introducing such features.

Just picking the [most recent blog post (from last month)](https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass) from Michał Bentkowski, there is a new mXSS bypass that is enabled by MathML. (From my reading of the details, it seems to be two combined bugs in the **specs** for `<form>` and the MathML `<mglyph>` element.) As you know, MathML is relatively new, and is still being implemented in some engines, like Chromium. An existing site, being viewed in a browser that now understands MathML, is **now** susceptible to this bypass, when it was safe before. 


> Simple fix proposal from a simple mind like me:
> Find a way to allow the DOM-based sanitizer to see a closed shadowroot as an element - not a text node.
> 
> Or am I oversimplifying things here? I might because as DOMPurify maintainer I am wearing sanitizer-glasses and might not understand the impact on other areas in full.

@cure53, thanks for the suggestion, but unfortunately, this would break Shadow DOM. Closed shadow roots are [designed](https://developers.google.com/web/fundamentals/web-components/shadowdom#closed) to be completely invisible to Javascript. Shadow roots in general don't even show up as a text node, they're only accessible from `element.shadowRoot`.

-- 
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-717311825