Trac does not properly escape embedded (X)HTML sequences

[Emmanuel Blot]

Using the following verbatim block:

<select name="foobar">
  <option>foo</option>
  <option>bar</option>
</select>

with a "!#html" bang line for syntax highlighting, Trac displays

foo bar

I guess this could be used to send unauthorized data to the server through POST requests.
Any potential security risks ? - if not, feel free to decrease the severity of this ticket.

[Emmanuel Blot]

Playing around with this issue, I finally made Trac [on edgewall server] raise an exception:

Python traceback

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/modpython_frontend.py", line 210, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 452, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 312, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 194, in process_request
    self._insert_ticket_data(req, db, ticket, reporter_id)
  File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 396, in _insert_ticket_data
    actions = TicketSystem(self.env).get_available_actions(ticket, req.perm)
  File "/usr/lib/python2.3/site-packages/trac/ticket/api.py", line 54, in get_available_actions
    return [action for action in actions.get(ticket['status'], ['leave'])
TypeError: list objects are unhashable

Unfortunetly, although I've been able to reproduce it several times, I'm not able to define the exact sequence of events that triggered this exception. It definitely comes from the HTML code (select/option) I wrote in the comment textarea.

[Christian Boos]

See my follow-up on #280: You should use #!xml instead of #!html if what you want is syntax highlighting.

OTOH, the #!html processor is for embedding HTML, so exactly what it does in the description above. Javascript and dangerous tags are forbidden in embedded HTML fragments, so there should be no risk.

I'll try to reproduce the exception you got above (was the exception triggered when viewing #280 or this one?)

[Emmanuel Blot]

I've been able to reproduce the exception within both bugs (I detected it first while previewing a comment for #280, then tried to reproduce it with the description of #1971)

The way to reproduce is hard to describe. After several previews of html syntax, I got the exception (Firefox 1.0.6, win xp2). Then, what ever the content of the comment textarea I put, even without any HTML tag, I got the same error every time I selected 'Preview'.

But, starting from another ticket, I've not been able to reproduce it with the HTML syntax that first triggered the exception. I had to play around (several previews, changing the HTML syntax just a little bit every time) to be able to trigger the exception once more.

[Emmanuel Blot]

BTW, isn't that weird to use XML color syntax switch for non-XML syntax ? (HTML, not XHTML)

Is there no risk to overwrite some Trac form fields using this embedded HTML ?

[Matthew Good]

Form fields on their own won't really do anything if they're not inside the <form> block. I'm not sure how much risk it presents, but <form> tags could be disallowed in #!html blocks if necessary.

The #!xml processor will probably handle even malformed HTML reasonably, although you can use the mime type instead as #!text/html

<a href="test">Testing</a>

You can use any mimetype recognized by Trac as a processor name.

[Christopher Lenz]

As far as I can tell, this works as intended.

[Christian Boos]

(clearing report:35)