Skip to content
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

Switch to dompurify for sanitizing markdown content #131950

Merged
merged 11 commits into from
Sep 3, 2021
Merged

Conversation

mjbvz
Copy link
Collaborator

@mjbvz mjbvz commented Aug 31, 2021

Switches us from using insane to instead use dompurify, which seems to be better maintained and also has some nice features, such as built-in trusted types support

I've tried to port over our existing sanitizer settings as best as possible, but there's not always a 1:1 mapping between how insane works and how dompurify does. I'd like to get this change in early in the iteration to catch potential regressions

@mjbvz mjbvz added this to the September 2021 milestone Aug 31, 2021
@mjbvz mjbvz self-assigned this Aug 31, 2021
@mjbvz
Copy link
Collaborator Author

mjbvz commented Aug 31, 2021

Assigning:

@jrieken For trusted types
@alexr00 For sanitization of markdown strings (specifically the allowed styles)
@JacksonKearl For welcome page

Copy link
Member

@jrieken jrieken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

return removeEmbeddedSVGs(raw);
const x = sanitize(raw);
console.log(raw);
console.log(x);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

console.log

@mjbvz
Copy link
Collaborator Author

mjbvz commented Aug 31, 2021

@jrieken Any idea on why I now get the eslint error in dom.ts:

 [ban-element-innerhtml-assignments] Assigning directly to Element#innerHTML can result in XSS vulnerabilities.

The code looks like:

		const html = dompurify.sanitize(value, { ...options, RETURN_TRUSTED_TYPE: true });
		node.innerHTML = html as any;

Where html is a TrustedHtml object

We were previously assigning to innerHTML as well, so I'm not sure why this error seems to have just started showing up. Also not sure how to fix it

@jrieken
Copy link
Member

jrieken commented Sep 1, 2021

We were previously assigning to innerHTML as well, so I'm not sure why this error seems to have just started showing up. Also not sure how to fix it

@mjbvz fd122aa isn't the best way to tackle this. A special sequence of casts is needed here... XYZ as unknown as string, see #106396 (comment) for more details

@jrieken
Copy link
Member

jrieken commented Sep 1, 2021

fyi - I have pushed two commits

  • e837c9b which is not great but better than the exemptions
  • a6cc048 makes the monaco-esm build happy (hopefully 🤞 )

Switches us from using `insane` to instead use `dompurify`, which seems to be better maintained and also has some nice features, such as built-in trusted types support

I've tried to port over our existing sanitizer settings as best as possible, but there's not always a 1:1 mapping between how insane works and how dompurify does. I'd like to get this change in early in the iteration to catch potential regressions
innerHTML can return different results on different browsers. Use `isEqualNode` instead
I beleive this is required since we allow links to commands and loading images over remote
mjbvz added a commit that referenced this pull request Sep 3, 2021
Fixes #40607

This change introduces a new `supportsHtml` property on `MarkdownString` that can be used to enable rendering of a safe subset of tags and attributes inside of markdown strings

For backwards compatability, `supportsHtml` will default to false and must be explicitly enabled by extensions

This PR will need to go in after we adopt dompurify (#131950) which should provide better control over how we actually go about sanitizing rendered html
@mjbvz mjbvz merged commit 474d495 into main Sep 3, 2021
@mjbvz mjbvz deleted the dev/mjbvz/dompurify branch September 3, 2021 19:17
@mjbvz
Copy link
Collaborator Author

mjbvz commented Sep 3, 2021

Thanks everyone! Merging in to get testing in insiders to catch potential regressions

mjbvz added a commit that referenced this pull request Sep 3, 2021
Fixes #40607

This change introduces a new `supportsHtml` property on `MarkdownString` that can be used to enable rendering of a safe subset of tags and attributes inside of markdown strings

For backwards compatibility, `supportsHtml` will default to false and must be explicitly enabled by extensions

This PR will need to go in after we adopt dompurify (#131950) which should provide better control over how we actually go about sanitizing rendered html
mjbvz added a commit that referenced this pull request Sep 3, 2021
Fixes #40607

This change introduces a new `supportsHtml` property on `MarkdownString` that can be used to enable rendering of a safe subset of tags and attributes inside of markdown strings

For backwards compatibility, `supportsHtml` will default to false and must be explicitly enabled by extensions

This PR will need to go in after we adopt dompurify (#131950) which should provide better control over how we actually go about sanitizing rendered html
@github-actions github-actions bot locked and limited conversation to collaborators Oct 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants