Skip to content

v6.0.1
Compare
Choose a tag to compare
@rgrove rgrove released this 27 Jan 18:22
· 27 commits to main since this release
v6.0.1
This tag was signed with the committer’s verified signature.
rgrove Ryan Grove
SSH Key Fingerprint: thRC0SH42U0BGrkfOqydLps8tamqIti0xPgo3ydFNrk Learn about vigilant mode.
a92f21c
This commit was signed with the committer’s verified signature.
rgrove Ryan Grove
SSH Key Fingerprint: thRC0SH42U0BGrkfOqydLps8tamqIti0xPgo3ydFNrk Learn about vigilant mode.

Bug Fixes

  • Sanitize now always removes <noscript> elements and their contents, even when noscript is in the allowlist.

    This fixes a sanitization bypass that could occur when noscript was allowed by a custom allowlist. In this scenario, carefully crafted input could sneak arbitrary HTML through Sanitize, potentially enabling an XSS (cross-site scripting) attack.

    Sanitize's default configs don't allow <noscript> elements and are not vulnerable. This issue only affects users who are using a custom config that adds noscript to the element allowlist.

    The root cause of this issue is that HTML parsing rules treat the contents of a <noscript> element differently depending on whether scripting is enabled in the user agent. Nokogiri doesn't support scripting so it follows the "scripting disabled" rules, but a web browser with scripting enabled will follow the "scripting enabled" rules. This means that Sanitize can't reliably make the contents of a <noscript> element safe for scripting enabled browsers, so the safest thing to do is to remove the element and its contents entirely.

    See the following security advisory for additional details: GHSA-fw3g-2h3j-qmm7

    Thanks to David Klein from TU Braunschweig (@leeN) for reporting this issue.

  • Fixed an edge case in which the contents of an "unescaped text" element (such as <noembed> or <xmp>) were not properly escaped if that element was allowlisted and was also inside an allowlisted <math> or <svg> element.

    The only way to encounter this situation was to ignore multiple warnings in the readme and create a custom config that allowlisted all the elements involved, including <math> or <svg>. If you're using a default config or if you heeded the warnings about MathML and SVG not being supported, you're not affected by this issue.

    Please let this be a reminder that Sanitize cannot safely sanitize MathML or SVG content and does not support this use case. The default configs don't allow MathML or SVG elements, and allowlisting MathML or SVG elements in a custom config may create a security vulnerability in your application.

    Documentation has been updated to add more warnings and to make the existing warnings about this more prominent.

    Thanks to David Klein from TU Braunschweig (@leeN) for reporting this issue.

Contributors

leeN
Assets 2
Loading