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?

I don't think it's acceptable to go ahead & accept this XSS vulnerability risk just because we don't have a concrete example.

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

Again, it's not acceptable to introduce a new security vulnerability risk just because there is a low number.

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

Again, it's not okay to introduce a new security vulnerability risk just because we can't easily find examples.

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

Given MathML had been supported by Firefox and WebKit for more than a decade, I'm not certain that we could claim that this is new XSS issue. But if it is, the correct approach is to fix the spec & implementation, not to go ahead & introduce the security vulnerability.


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