[mXSS] Consider making HTML parsing of `style`, `script`, `xmp` etc consistent between SVG, MathML, HTML

[zcorpan]

What is the issue with the HTML Standard?

Elements that are parsed as RAWTEXT or RCDATA in HTML context but as normal elements in foreign content context have been used for mXSS vectors. Examples:

• https://research.securitum.com/dompurify-bypass-using-mxss/
• https://x.com/Sonar_Research/status/1866135979880300830
• https://bughunters.google.com/blog/5038742869770240/escaping-and-in-attributes-how-it-helps-protect-against-mutation-xss#does-this-change-prevent-all-mxss-vectors-

Some also used the fact that < and > were not escaped in attribute values, which was fixed in #6362. But mXSS attacks are likely still possible.

Elements of interest:

• title
• textarea
• style
• script
• xmp
• iframe
• noembed
• noframes
• noscript
• plaintext

In https://x.com/zcorpan/status/1339517144053243906 I argued that it would have been better to have consistent parsing of style (and others) between HTML and in foreign content. Then, a mutation that causes a style element to be in a different namespace after parse-serialize-parse wouldn't matter.

It's not clear if it's still possible to change this, or if there's web content that depends on style, script or title in SVG to have normal parsing. Also, changing this would likely cause some problems until all parsers agree on the new parsing. But in the long term it may be better if we can solve the mXSS vector completely.

(Another feature that is conditionally available based on the current element during parsing is CDATA sections. Maybe it's possible to make them work in HTML context also?)

cc @whatwg/html-parser

[securityMB]

Thanks for raising this issue!

Some also used the fact that < and > were not escaped in attribute values, which was fixed in #6362. But mXSS attacks are likely still possible.

That's definitely the case, here's an example of mXSS which didn't rely on the fact that < and > used to not be escaped.

It's not clear if it's still possible to change this, or if there's web content that depends on style, script or title in SVG to have normal parsing. Also, changing this would likely cause some problems until all parsers agree on the new parsing. But in the long term it may be better if we can solve the mXSS vector completely.

So I think the way to go here would be to add a use counter that would trigger if <style>, <script>, <title> and other similar tags would have anything else as children than text nodes?

[zcorpan]

That's definitely the case, here's an example of mXSS which didn't rely on the fact that < and > used to not be escaped.

Did you mean to add a link?

So I think the way to go here would be to add a use counter that would trigger if <style>, <script>, <title> and other similar tags would have anything else as children than text nodes?

Yes, or (except for title and textarea) if they use character references. CDATA sections (which are inserted as normal text) are also of interest.

[securityMB]

Did you mean to add a link?

Ah, sorry, yes. Here it is: https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/

[0xtenso]

Hello there!
Could you give me chance to work with you?