-
-
Notifications
You must be signed in to change notification settings - Fork 372
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
Carefully constructed markup sneaks tags through as "text" #105
Comments
👍 |
Sorry for the late response. @boutell You can enable entity decoding using |
Thanks for the update. A pity it won't be fixed soon, but hey, we're not On Mon, Oct 20, 2014 at 2:44 PM, Felix Böhm [email protected]
*THOMAS BOUTELL, *DEV & OPS |
htmlparser2 3.8.2 has known vulnerabilities: fb55/htmlparser2#105 ↳ jshint 2.5.10 ↳ htmlparser2 3.8.2 But we don't care; it's only a development dependency.
As this seems to be confusing for a lot of people: This is not a vulnerability, but instead a bug in @boutell's module. The behavior is in-line with the HTML spec (I wasn't sure about it in my previous comment). Entities aren't decoded by default, only not to break backwards compatibility, but will be in the next major release (which will mainly consist of #114, I only need to take a day and add positional support to high5). It is recommended to always decoded entities, then use eg. For now, I'll add a note to the wiki page recommending to always enable |
OK, version 1.5.1 of sanitize-html uses decodeEntities: true and passes its filter evasion tests without the need for recursive invocation. Thanks. If the behavior with decodeEntities: false is inherently unsafe I wonder if it should be offered at all in the next release. But maybe it has an application I'm not seeing. |
Always depending on |
issue fb55/htmlparser2#105 has not been fixed yet
false positive (albeit it could use more secure default) see fb55/htmlparser2#105
This code:
Results in the following sequence of onopentag/ontext/onclosetag events:
text: < open: img (with the expected src attribute) close: img text: img src="javascript:evil"/>
Since the sanitize-html module trusts "text" coming from htmlparser2, and outputs it without further escaping (because htmlparser2 does not decode entities in text before delivering it), this results in an XSS attack vector if sanitize-html ignores the img tag (according to user-configured filter rules) but passes the text intact, as it must do to keep any text in documents.
I have verified that the bug still exists as of version 3.7.3.
The text was updated successfully, but these errors were encountered: