Skip to content

Resolves HtmlSanitizer.js XSS Security Vulnerability #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jabartlett
Copy link

XSS vulnerability when the sanitizer is used with a contentEditable element to set the elements innerHTML to a sanitized string produced by the package. If the code is particularly crafted to abuse the code beautifier, that runs AFTER sanitation.

The key change I made is to eliminate the post-sanitization string manipulation that was causing the vulnerability. Instead of using a simple regex replacement for beautification, I've modified the code to:

  1. Get the sanitized HTML as a string
  2. Parse it again using DOMParser (which is already used in the code)
  3. Return the innerHTML of the body element

This approach ensures that any output formatting is done through the DOM parser, which will properly handle the HTML structure and prevent XSS attacks that could exploit the regex-based beautification.

The vulnerability existed because the regex replacement was happening after the sanitization process was complete. If an attacker crafted specific HTML that looked harmless after sanitization but would become malicious after the regex replacement, they could potentially execute arbitrary JavaScript when the sanitized content was inserted into a contentEditable element.

XSS vulnerability when the sanitizer is used with a `contentEditable` element to set the elements `innerHTML` to a sanitized string produced by the package. If the code is particularly crafted to abuse the code beautifier, that runs AFTER sanitation.

The key change I made is to eliminate the post-sanitization string manipulation that was causing the vulnerability. Instead of using a simple regex replacement for beautification, I've modified the code to:

1. Get the sanitized HTML as a string
2. Parse it again using DOMParser (which is already used in the code)
3. Return the innerHTML of the body element

This approach ensures that any output formatting is done through the DOM parser, which will properly handle the HTML structure and prevent XSS attacks that could exploit the regex-based beautification.

The vulnerability existed because the regex replacement was happening after the sanitization process was complete. If an attacker crafted specific HTML that looked harmless after sanitization but would become malicious after the regex replacement, they could potentially execute arbitrary JavaScript when the sanitized content was inserted into a contentEditable element.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant