Symphony.

Hey guys,

I’m in the process of building a site with Symphony, and I’m nearly done; there is just one huge problem. The comments system is vulnerable to XSS in pretty much every way possible.

For example, I can add a link: Example; or, in the website name field on the comments form, I can put:

javascript:(javascriptcodehere)

And it will be executed without an issue. I really don’t want my visitors being subjected to XSS attacks, and I have no idea how to properly sanitize output (or even input) in Symphony. The fact that this site is even vulnerable makes me wonder if it’s possible.

Any ideas?

oh snap!

Yeah, I’m surprised this is possible on this site, and I doubt most Symphonians guard against it. That said, you can always filter any user-generated content when you are outputting it. It would be ideal if it could be filtered before its saved to the db.

Text-formatters should be handling that (E.G. Markdown). I’ll need to look into why it isn’t working though.

The site should have JS sanitisation, it’s been added to the markdown formatter a while ago. Looking at why it’s not applying here.

Edit: Alistair beat me to it

Okay, so it should be sanitized, but isn’t?

In that case, what should I do for now? I’d like to go live with my site, but there is no way I can let a vulnerability like this through.

Edit: For now, I’m just running HTMLPurifier in a slightly modified TextFormatter class.

Edit: For now, I’m just running HTMLPurifier in a slightly modified TextFormatter class.

Funny you should mention that. I have just updated the Markdown extension to include HTML Purifier. http://github.com/pointybeard/markdown

I am in the process of deploying it to this site now.

Hoping that fixed the problems. Lets see Click Me and now a normal link — Symphony CMS Site

So is the Markdown + HTMLPurifier extension production ready? If so maybe it could be a forum sticky or some such?

For user-generated content I would suggest to use the Ninja Utility in order to only allow certain tags anyways.

Funny you should mention that. I have just updated the Markdown extension to include HTML Purifier. http://github.com/pointybeard/markdown

I am in the process of deploying it to this site now.

Great, thanks! The last thing I’ve noticed is that the default URI filter in Symphony allows for javascript injection as well; for example, on a default install of Symphony, type this for your website name in the comments field on an article:

javascript:alert(‘XSS’);

It will pass the filter without any problems, and will be executed should the user click the malicious user’s name with a link to their site.

@Alistair What do you think about cleaning all GET and POST variables before any database action?

@Alistair What do you think about cleaning all GET and POST variables before any database action?

Symphony already does that. Although only to protect its database (escape all quotes etc, you know the game). However, I do not recommend to add something like “remove all Javascript” to the core DB sanitation rules as it’s clearly not a task the core should be doing.

However, I do not recommend to add something like “remove all Javascript” to the core DB sanitation rules as it’s clearly not a task the core should be doing.

Absolutely. Take the case whereby you are a blog owner and you are posting JavaScript code samples. The best option in my opinion is to use a Markdown text formatter and use the Ninja XSLT technique on the frontend to manipulate the markup to render only safe elements.

use the Ninja XSLT technique on the frontend to manipulate the markup to render only safe elements.

This is exactly the way I do it. (if I allow tags at all, mostly I just use value-of, so no tags get through anyway..)

In my experience no xss safe cms has ever been built. As almost every big website is unique, and the exploits are too, it is almost impossible to build a standard solution. (what could be regarded as a flaw could be by design in another website)

The most important thing is to always think about those exploits while building, and preventing the ones dangerous for the website.

So no word on the built-in regexps? It’s trivial to change them, but it would be nice if they were more secure by default.