XSS scripting attack possible from html wikiprocessor

[dkg-debian.org@…]

Using the html WikiProcessor, it's possible to inject a malicious script (for example, a cookie-stealing attack) against other clients viewing the page with IE or Opera (and possibly other browsers).

As an example of this Cross-Site Scripting (XSS) attack, consider the following:

{{{
#!html
<IMG SRC="javascript:alert('XSS');">
}}}

When viewing a page with this code inserted under opera or IE (i think — don't have a windows box handy for testing), a javascript alert dialog box should pop up with the text "XSS". Transforming this into a cookie-stealing attack or other malicious activity is left as an exercise to the reader.

Trac has done a decent job about filtering the more obvious of these in the html WikiProcessor (e.g. Trac disallows the <script> tag), but overly-permissive browsers make this a much tricker problem.

For more information about some other possible XSS vectors, see ​http://ha.ckers.org/xss.html

[dkg-debian.org@…]

i just tested this on IE 6.0.2800.1106, and the 'XSS' dialog box does indeed pop up.

Firefox and Mozilla seem to be immune to this particular attack, but they may be vulnerable to other attacks.

a couple of workarounds occur to me:

• disabling the html WikiProcessor entirely
• disabling the html WikiProcessor for text that is authored by non-privileged users. Given that the wiki nature suggests that there isn't a single author for most documents, this could be very difficult to do accurately. I don't know if there is enough author-tracking infrastructure in Trac to make this approach possible.

[anonymous]

Add an option to disable the use of JavaScript in the WikiProcessor entirely.

It's simple, and puts the liability in the users hands, not yours. Many websites and scripts have these options. Remember, not everyone uses quality software :)

It could easily be implemented through catching certain keywords in input whenever the user does a preview or submits the page, or even fighting fire with fire by using javascript on the input area whenever a key is pressed, though that's a bit unrealistic. Checking for matches like "java", "javascript" etc. in the input text would be okay.

[dkg-debian.org@…]

The problem is even simpler than anonymous says. The point is: all JavaScript should be disabled in every WikiProcessor no matter what. Otherwise, a wiki site is vulnerable to Cross-Site Scripting, by definition. if you allow javascript, you allow cookie-stealing and a host of other malicious activity. The example popup displayed here is a trivial inconvenience by comparison. However, the solution is not as simple as anonymous would have it. If you checked for matches like "java" or "javascript", for example, the comment from 12/26/05 16:16:04 by anonymous wouldn't have been allowed, because the body of the comment itself matches that text. And you also need to consider shoddily-constructed browsers (like IE) which don't even do reasonably strict parsing of html (c.f. ​the myspace worm). in that case, you need to strip out a lot more than just a case-insensitive "javascript" string.

[dkg-debian.org@…]

sorry: changing the summary back to the original summary. i thought when i filled it in at first that it was the summary for comment i was making, not for the whole ticket. it should now be back to normal.

[Christopher Lenz]

This should be fixed in trunk in [2700]. The HTML snippets are completely parsed and rewritten, removing anything potentially abusable. I'll leave this ticket open until the changes have been merged back into 0.9-stable.

[Christopher Lenz]

Wrong milestone.

[Christopher Lenz]

Fixed in 0.9-stable in [2724].