Edgewall Software

Opened 17 years ago

Closed 17 years ago

Last modified 14 years ago

#2473 closed defect (fixed)

XSS scripting attack possible from html wikiprocessor

Reported by: dkg-debian.org@… Owned by: Christopher Lenz
Priority: high Milestone: 0.9.3
Component: general Version: 0.9.2
Severity: normal Keywords: security
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


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:

<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

Attachments (0)

Change History (7)

comment:1 by dkg-debian.org@…, 17 years ago

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.

comment:2 by anonymous, 17 years ago

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.

comment:3 by dkg-debian.org@…, 17 years ago

Summary: XSS scripting attack possible from html wikiprocessorclarifications after anonymous comments.

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.

comment:4 by dkg-debian.org@…, 17 years ago

Summary: clarifications after anonymous comments.XSS scriptingattack possible from html wikiprocessor

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.

comment:5 by Christopher Lenz, 17 years ago

Milestone: 0.9.4
Owner: changed from Jonas Borgström to Christopher Lenz
Priority: normalhigh
Status: newassigned

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.

comment:6 by Christopher Lenz, 17 years ago


Wrong milestone.

comment:7 by Christopher Lenz, 17 years ago

Resolution: fixed
Status: assignedclosed

Fixed in 0.9-stable in [2724].

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.