-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Sanitize hardening #1504
Sanitize hardening #1504
Conversation
I think we should have a list of sanitizers in our docs and recommend using one of them instead of just recommending DOMPurify. something like this list |
Works for me! I personally recommended DOMPurify because its creators (Cure53) are one of (if not the) experts of the fields with a proven track record of finding critical bugs in even most well-known libraries / services. Sanitize-html also looks good, but I am not sure about the other two. Should we create a docs .MD file about these options and link to that file from the code and from other documentation? |
I would just add the list under the options and link to that section in USING_ADVANCED.md |
@@ -39,7 +39,7 @@ Also read about: | |||
|
|||
## Usage | |||
|
|||
### Warning: 🚨 Marked does not [sanitize](https://marked.js.org/#/USING_ADVANCED.md#options) the output HTML by default 🚨 | |||
### Warning: 🚨 Marked does not [sanitize](https://marked.js.org/#/USING_ADVANCED.md#options) the output HTML. Please use a sanitize library, like [DOMPurify](https://github.com/cure53/DOMPurify) (recommended), [sanitize-html](https://github.com/apostrophecms/sanitize-html) or [insane](https://github.com/bevacqua/insane) on the output HTML! 🚨 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we have this list in one place and just link to it. I feel like it will be hard to keep these lists in sync if we ever have to update them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any suggestion where would you like to put that list exactly? It's your project afterall and I feel like this is the point where this change has nothing to do with the security fix.
Also there are already two README.mds (/README.md
and /docs/README.md
) with similar content, so you have to keep those in sync too...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@koczkatamas: Thank you so much for this!
@styfle: Where would the best place be to store this list? Thinking it would be a nice list for users moving forward as we are planning to get out of the sanitizer business and working looking for things like this anyway. (I have a note to catch up on what I've missed with all the weirdness of life soon.)
OK, finally had a chance to review this. If I understand correctly, I see 2-3 problems being discussed.
I agree that deprecating the sanitization feature seems like a good path forward.
|
@@ -434,7 +434,7 @@ Lexer.prototype.token = function(src, top) { | |||
: 'html', | |||
pre: !this.options.sanitizer | |||
&& (cap[1] === 'pre' || cap[1] === 'script' || cap[1] === 'style'), | |||
text: cap[0] | |||
text: this.options.sanitize ? (this.options.sanitizer ? this.options.sanitizer(cap[0]) : escape(cap[0])) : cap[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be a semantic change for anyone using this feature, right? Same comment on the similar line below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, for example if their code allowed XSS then now it won't. 😉
There are no test cases on how the sanitizer should work, so basically any previous change could change this feature also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is, if anyone is currently invoking marked with the sanitize option, the output may change if we land this PR.
- Yes, they will be (less) XSS-able
- But since we didn't really document what "sanitize" did, they might have enjoyed its previous behavior (e.g. assuming that by sanitize we meant removing unclosed HTML tags or similar).
As a result I'm not sure how to semver this.
Looking for @davisjam to approve this one to the point of merge as I don't have the security knowledge to feel right in doing it. With that said, given the plan to get out of the sanitizer business altogether by 1.0 - I'm pretty okay here. If the community can hit 100% CommonMark compliance and no known security issues, 1.0 should be released and we can begin the work of refactoring and re-engineering toward the single responsibility of parsing markdown and letting the inputs and outputs be handled by extension or somewhere else altogether. EDIT: That might seem left-field. If this fixes the known security issue, great. If we are at 100% CommonMark compliance, great. We can release 1.0 and remove all the sanitizer logic along with all related corrections and workarounds, including this one. |
Here is our current gfm and commonmark compliance chart:
We have a long way to go on some of the sections |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK to land this, but as I've noted in my comments, we should be careful with the semver on the release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also agree this should be considered a breaking change
Marked version: master
Markdown flavor: all
Description
Expectation
HTML sanitized properly if
sanitize: true
is usedResult
There is a known bypass of sanitization
What was attempted
Fixed the known bypass, but I expect other bypasses, so Marked now warns its users not to depend in
sanitize: true
, but use other means of sanitization (e.g. DOMPurify).-->
Contributor
Committer
In most cases, this should be a different person than the contributor.