A common bug in comment preview that leads to an XSS attack

[Daniel Martin <martin () snowplow org>]

Recently, I have noticed that many blogs or other fora that allow
user-posted comments suffer from a common bug with regards to comment
preview, such that the comment previewing feature can be exploited
with an XSS type 1 attack.

To test if your favorite blog is vulnerable in this fashion, enter
this comment text and preview it:

</textarea>
<script>document.getElementsByTagName('body')[0].innerHTML=
'<h1>XSS injection successful</h1>';
alert(document.cookie);</script>

Many blogs that offer comment preview do not escape the user's input
when re-presenting that input for further editing; instead, they send
this to the browser:

<textarea>(User's input, verbatim)</textarea>

This means that when previewing the above text, the browser is sent:
<textarea></textarea>
<script>document.getElementsByTagName('body')[0].innerHTML=
'<h1>XSS injection successful</h1>';
alert(document.cookie);</script></textarea>

For example, Moveable Type blogs contained this error until version
3.32 (released 2006-08-28), and the announcement for version 3.32 did
not mention this change as a XSS vulnerability issue.  (Subsequent
versions' announcements mentioned various other XSS attacks, so at
this point the user population should have been warned)

A similar situation may exist in the "name", "email", or other fields
- the test there is to enter a name of:
  "><script>alert('name vulnerable');</script>

(and similarly for the email and url fields)

The solution for writers of blogging/commenting software is of course
to always html-escape user input when it is being sent as the content
of a textarea block.  Note that in many cases, this bug could have
been avoided if major browsers were not so liberal in their treatment
of unencoded <, >, and & inside a <textarea> block.  That is, if some
major browsers decided to render this:

<textarea><i>hi</i></textarea>

in an identical fashion to this:

<textarea>hi</textarea>

(that is, strip out all unescaped tags inside a textarea block)
then programmers of blogging/commenting software might more often
realize that the contents of a textarea need to be html-escaped.

Note that in addition to presenting an XSS vulnerability, software
with this bug inconveniences users during normal use of the
application if the blog in question uses some form of html formatting
in the comments such that one must type &lt; to obtain a less-than
symbol in the comment.

For example, a popular math discussion blog suffers from this bug, and
this results in:

  A user is typing a comment and wishes to say:

    For all a and b > 1, gcd(a,b) < b. Therefore, you are wrong.

  The user types into the textarea box:

    For all a and b &gt; 1, gcd(a,b) &lt; b. Therefore, you are wrong.

  Now, if at this point the user simply hits "post comment", the
  comment is posted as the user intended.  If, however, they hit
  "preview", see that the preview looks as intended, and then hit
  "submit", the user's coment is posted as:

    For all a and b > 1, gcd(a,b) 

  since the user's &gt; and &lt; were transformed into a simple > and
  < by the preview-submit cycle.

Note that the fact that users are in some cases inconvenienced by this
bug during the regular use of this software means that this
vulnerability may be stumbled upon by even initially benign users.
(i.e. not just by people deliberately looking for trouble)