I'm not convinced that there's a one-size-fits-all filtering solution that can make all user input safe -- there will always be edge cases where user data will get mangled. I feel more comfortable tackling this from the other direction and making sure that data output in the templates is always properly escaped. I realize that it's very hard to catch every possible security hole by doing things this way, but it's less likely to cause unanticipated side effects, and there's no harm in it since it can still complement a lower-level solution like Till's proposed quick fix (which might help if you're paranoid, but which I would not advocate incorporating in the trunk code).

I eventually hope to do a thorough review of all templates to identify and fix XSS problems. In the meantime, I have been patching problems whenever I notice them, and I try to inspect all new SVN commits for potential issues. Additionally, injecting Javascript should be part of standard testing procedure whenever we introduce features that take user input to prevent new problems from springing up.

As of r1802, I have reviewed all templates for encoding/escaping problems. This should solve all known XSS vulnerabilities as of this writing, so I am closing the ticket.

Obviously, XSS problems are easily reintroduced, so we need to keep this in mind in the future. Feel free to reopen this (or open a new ticket) if you find new problems or if you have thoughts on more thorough input-side cleaning (since I've really only addressed the output side of the equation for the moment).