Joomla Open Source Web Content Management System (Web CMS)
Jeff Channell is a web guy who I've seen frequently volunteer his time in the Joomla security forum. He has found several Joomla extensions with XSS Vulnerabity exploits. He was kind enough to answer some questions about what an XSS Vulnerabity is and how Joomla site managers can best defend against them.

John Vanover: Even for us advanced beginners the xss vulnerability issue can be hard to wrap our heads around, can you provide a brief description of the exploit for us laypeople?

Jeff Channell: XSS vulnerabilities come in many flavors. There are URI vulnerabilities, where portions of the page request get rendered into the page at the time of the request without sanitation or validation. These types of XSS are generally only exploitable by sending a malformed link to an unsuspecting user, though sometimes can be used for Persistent XSS.

Persistent XSS is a particularly nasty attack vector, and the one every web developer should be concerned with. In this form of attack, the attacker's code persists after a page request. The recent vulnerabilities I've found in a couple of forum components are of the Persistent type, leveraging bugs in the BBCode implementations that render my script to anyone visiting forum posts I've attached scripts to.

This does not mean, however, that BBCode is the only method of exploiting XSS. Recently, I found a vulnerability in Agora that allowed for arbitrary file upload in the attachment feature, as it only checked for an extension instead of a mime-type. Add to this the SWF embedding feature and Flash's externalInterface class, and it was game over.

JV: Are there certain types of extensions that are more vulnerable to xss vulnerability?

JC: Any component that renders user-supplied input could be susceptible, such as forums, guestbooks, etc. And this goes double for components that render user-supplied input in the administrative back-end.

JV: I see XSS vulnerabilities addressed in firefox updates, etc. What other software/cms are at risk to xss vulnerabilities?

JC: I don't want to sound negative, but any software could possibly allow execution of third party code, whether it's XSS through JavaScript, injecting server-side code (PHP, ASP, etc.), or even buffer overflows in compiled apps. As I write this, there's a vulnerability in the wild for Firefox 3.5 that allows arbitrary code execution due to a bug in the new JavaScript engine's document.write method. The code used to cause the buffer overflow is written in JavaScript, but the payload is not.

JV: How to best evaluate ones own sites for xss vulnerability issue?

JC: The best way to do this is to test everything that accepts user-supplied input with test code. Try submitting your forms using <hr> tags, and if you get a horizontal line, it stands to reason a malicious hacker could replace that with a <script> tag. Try passing single and double quotes, and check the resulting source as to what really gets rendered. If you can inject a < without it being stripped or converted to it's html entity, or an injected quote can throw off a tag being rendered properly, that's a bad thing.

Get a copy of Firefox and use the Web Developer plugin. The form tools are really great for penetration testing. For example, the auto completion is really nice, and being able to remove the maximum character limit on input fields allowed me to find a Persistent XSS in SOBI2, which renders scripts in the administrator backend!

There are a lot of things besides XSS to worry about. Don't forget about URL parameters. SQL Injections are a danger, as well as Local File Includes, Remote File includes, etc.

Stay on top of security news, and not just by subscribing to the Joomla Security newsletter. The number one place to go is, which is hands down the best place to stay updated on what vulnerabilities are coming out. There are others as well, but milw0rm is the best!

[Editor's Note: See the Joomla Security Center for detailed resources on protecting your Joomla website.]

JV: What should we look out for, going forwards, with the XSS issue?

JC: Stay vigilant, and test your components! Watch for strange behavior on your site, whether in your Apache logs, 3rd party logging, or user registrations, etc.

The best advice I could give for vulnerabilities in general is to break your site. I mean it: any invalid input that you can force your site to accept poses a potential security breach. Even small things like PHP errors that display the absolute path of a file could be used as part of an attack.