12

The OWASP XSS Prevention Cheat Sheet has a list of locations where untrusted data should never be put:

 <script>...NEVER PUT UNTRUSTED DATA HERE...</script>   directly in a script

 <!--...NEVER PUT UNTRUSTED DATA HERE...-->             inside an HTML comment

 <div ...NEVER PUT UNTRUSTED DATA HERE...=test />       in an attribute name

 <NEVER PUT UNTRUSTED DATA HERE... href="/test" />   in a tag name

 <style>...NEVER PUT UNTRUSTED DATA HERE...</style>   directly in CSS

I understand why data shouldn't be put into the other 4 places, but what is the danger of putting user input into HTML comments? I would think that encoding > would be enough to prevent any attacks. Is there a way to execute JavaScript inside a HTML comment? Or a different way to exit HTML comments without >?

Improve this question

2 Answers 2

Reset to default
13

The relevant entries in the HTML5 Security Cheatsheet are:

  • Ending HTML comments with a backtick character: html5sec#133 (IE6, IE8)
  • Injecting XSS or with a conditional comment html5sec#115 (older IE, IE quirks mode)

Apart from that user input might be used to change this comment into a conditional comment (IE only) and thus change the DOM or block the execution of script after the comment. This could change the behavior of the page in an unintended way.

Improve this answer
3
  • 2
    Another surprising thing: the -- part starts and ends a SGLM comment, which is inside an empty HTML tag. Older browsers had problem with <script><!-- some_code;decrement_this--;some_other_code --></script>, because the decrement operator ended the SGML comment.
    – allo
    Commented Jul 18, 2018 at 12:26
  • @allo Note that since it applies to only very old browsers (probably only IE before IE6), then I would not consider it as an issue. But HTML spec give a lot of restrictions about starting/ending a comment. Even if a lot of these involve a < or > character (which should be properly encoded by any HTML encoding function), it's worth checking.
    – Xenos
    Commented Jul 19, 2018 at 7:58
  • If you filter or modify the string to be inserted between comment limiters <!-- and --> to never include a double dash -- then it's safe in any HTML5 standards complicant browser. Nobody should care if it's safe with broken browsers because those will be unsafe no matter what you do.
    – Mikko Rantalainen
    Commented Jun 26 at 12:07
3

If untrusted data can be everything, we could inject for example --><script>alert("I just escaped the HTML comment")</script><!-- which would make it appear in source code like: <!----><script>alert("I just escaped the HTML comment")</script><!---->(Note the empty comments)

Improve this answer
2
  • True, but if I can inject -->, I'm not in a comment context anymore, but in a HTML element context. In that case, OWASP RULE #1 would apply, which says untrusted data may be printed if escaped.
    – tim
    Commented Jun 16, 2016 at 19:19
  • 1
    Exactly. Escaping the context is why it's written to OWASP as security vulnerability, as some people may not understand the mechanics of XSS overall, and they could think "Oh, so if I let users edit HTML comments, nothing bad can happend right?"
    – Eda190
    Commented Jun 16, 2016 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .