Built-in scrubbers don't escape unsafe HTML with Nokogiri > 1.15 about loofah HOT 2 CLOSED

Hi @stefannibrasil! This looks like a change upstream in libxml2

• upstream issue https://gitlab.gnome.org/GNOME/libxml2/-/issues/321
• upstream commit https://gitlab.gnome.org/GNOME/libxml2/-/commit/76d6b0d768d4e60a2d2844d55def120257ab6c6e

The maintainer calls out that $, [, and ] should not have been escaped, and are no longer as of libxml2 v2.11.0, which shipped in Nokogiri v1.15.0.

Unfortunately, since this is libxml2's behavior, it's not easy for nokogiri or loofah to change that behavior.

Can you help me understand why you think escaping that character is useful for security/sanitization?

from loofah.

Ahhh, thank you very much for the context, that's really helpful. So many things to learn 📚

Can you help me understand why you think escaping that character is useful for security/sanitization?

This was totally a misunderstanding on my end. I was reading OWASP cheat sheet where it mentions:

“HTML Context” refers to inserting a variable between two basic HTML tags like a <div> or <b>. For example..
<div> $varUnsafe </div>
An attacker could modify data that is rendered as $varUnsafe. This could lead to an attack being added to a webpage.. for example.

<div> <script>alert`1`</script> </div> // Example Attack
In order to add a variable to a HTML context safely, use HTML entity encoding for that variable as you add it to a web template.

However, the sanitized HTML would strip out the script tag anyway, so <div> $varUnsafe </div> would not be a security risk. Only if used solely without any previous sanitation.

I had a test that asserted characters with $ would be escaped but reading the docs you shared, I realize now it's not a security risk. Thank you so much for sharing. I will close this issue and move on with upgrading Nokogiri's 👀

from loofah.