4 ms·
It (thinks it) can’t do that because <style> introduces a special parsing mode where those character references would be interpreted literally.
by minitech 6y ago
It (thinks it) can’t do that because <style> introduces a special parsing mode where those character references would be interpreted literally.
- kijin 6y agoThen it needs to be better aware of what kind of syntax is allowed in CSS, because </math> clearly isn't valid CSS. Sanitizing HTML isn't just about removing unwanted tags and attributes. Assuming you want to preserve some styling, the sanitizer needs to be aware of the spec for not only HTML but also CSS, JS, SVG, and whatnot. It must ensure that it never emits output that would be invalid in any of those contexts. (JS is easy because you normally just delete it.) To date, I haven't seen any HTML sanitizer that's as serious about enforcing spec as HTMLPurifier. It strips out everything that isn't in a whitelist and guarantees that the output is syntactically valid. Unfortunately, it's written in PHP, its whitelist is kinda outdated, and nobody seems to want to port it to any other language. But the only alternative is to take dangerous shortcuts.
- missblit 6y agoNot sure strict CSS parsing would have avoided this issue, since you could just surround what the purifier thought was a style text node with /* and */ (which is valid CSS, being a comment)
- securitymb 6y agoEven if comments were stripped (which sometimes happens), you could still put it in the URL or font family name: * { font-family: '</math>...'; }
- kijin 6y agoSanitizers are not required to keep the original content intact. They absolutely can, and should, strip invalid and/or suspicious content from CSS strings.
- dataflow 6y agoAny idea if <script> has similar issues? I've always had it in the back of my mind that HTML parsing must have some problems if you mess with the code inside <script> tags too hard, but I've never gotten motivated enough to try to investigate.
- minitech 6y ago<script> is even more complicated than <style> as far as the HTML spec goes, I think. (There’s parsing weirdness where the behaviour of <!-- in <script> depends on whether </script> followed by --> is present somewhere, for example.) Not sure about whether DOMPurify supports non-executable <script>s.
- dataflow 6y agoOof. I'm not so worried about DOMPurify specifically but I've been thinking surely there's got to be some inconsistency between different browsers or libraries...