Symphony.

I think that integration with the OWASP ESAPI Library could benefit this project greatly. While the XSS filter provides basic Cross-Site Scripting attempts I don't believe that is as rich as the ESAPI Library. I would suggest this be added to the core but making an extension in the mean time would help against current attacks. Anyone else have thoughts on this?

While I generally agree on not-reinventing the wheel, security is the only place where I think it doesn't really hold up.

There can be no package that will fix all security flaws with all pieces of software, as the nature and parsing of the input will vary greatly. Because of the way XSLT and XML work, it is already quite hard to exploit Symphony with XSS (quotes and opening and closing tags are encoded, for instance). So far, the only problems I've seen have to do with stuff like markdown and external xml feeds getting hacked, and even these problems turned out to be no big deal: parsing the xml using the ninja technique took out the dangerous bits in the XML.

So, besides the fact that Symphony already handles this very well, the solution suggested here is rather complex: do you really expect your security filter to know in advance that the input will be parsed as markdown, plain text or pure html? And how do you expect it to filter it accordingly? Should it always filter out the javascript keyword, for instance?

Compare it to the effort of hacking a website: sure you can run an automated tool, and it will find 80% of the exploits, but not all. To find all of them you will still need to do a manual run. Security is no problem a "one size fits all" solution exists for, nor will it ever exist.

While I do agree that security can't be achieved by plugging in a magical black box and never worry again I must say I can't really follow your conclusions here.

Yes, we have our own XSS filter solution, and yes, it appears that XML and XSLT are robust templating langues. However it has shown time and time again that a custom non-standard solution just isn't as solid as concepts that have had the chance to prove themselves over the years (they even may make you look like a fool, for example in the case of the DVD encryption algorithm).

Any given security solution will never be as smart as the person writing it or the pair of eyes peer-reviewing it. Or as Bruce Schneier said (in that case about encryption algorithms, but it still holds here):

Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break.

In my eyes the more publicly known and used a security solution is, the more secure it becomes. If there were an issue to rise in ESAPI the chance of it being noticed without a symphony site being affected much more likely and there would be several people attempting to reproduce the issue and eventually fix it.

Anything else is just "security through obscurity" wich, when it comes to a properly thought through attack, may show to be just as secure as no security at all.

I am not saying we should specifically pick one solution over another but single handedly dismissing an awarded and often recommended community effort by people specializing in the area of websecurity just won't be very smart.

And besides, if you were right in saying Symphony is secure enough at the moment; would another layer of security really hurt?

@phoque of course security by obscurity is not the way forward, and it is also not what I am proposing.

Also, I am not against implementing ESAPI for general input sanitizing, replacing the regex'es we have now with something more rigid sounds like a good idea.

The only thing I am against is taking a library like ESAPI and think you can stop thinking after you've plugged it in. Especially with XSS this is a very bad idea, as most exploits are unique to each website, because the success of an attack really depends on where the input ends up in the end.

Let me illustrate this with an example: we are using markdown, so ![Image Alt](javascript:alert('xss')) might be rendered as an image which will execute javascript code (depending on the markdown implementation, of course). The only place where this attack can be stopped is in the markdown parser, or (less optimal) in the XSLT template.

If you want to stop an attack like that with general purpose filters, your only resort are very agressive filters that replace every javascript string from every input. This is quite a bad idea when you're running a blog about javascript, as you can imagine.

Now, another example: imagine a field where the user can submit the url to an image that will be displayed (as an avatar, for example). Now, when a malicious user uses an url like http://domain.com/users/make_admin/USER_ID and convinces an admin to open a page where the image is shown, he will be granted administrator rights.

XSS can be prevented either at the place where the layout is formed (xslt and markdown in the first example) or in the business logic (like requiring POST, or a password, in the second example). Trying to prevent it at the input won't work, which is why I think plugging ESAPI at the input and thinking we've solved the problem is a bad idea.

...I think plugging ESAPI at the input and thinking we've solved the problem is a bad idea.

Nobody suggested that. On the other hand, thinking about ESAPI is a good idea.

Also, ESAPI is not a set of regex rules but rather an API that provides method calls to sanitise stuff, i.e. strings to be used with a database.

ESAPI is not a set of regex rules but rather an API that provides method calls to sanitise stuff, i.e. strings to be used with a database.

I never disputed that:

I am not against implementing ESAPI for general input sanitizing, replacing the regex'es we have now with something more rigid sounds like a good idea.

The topic is explicitly about XSS, and my point is that filters are not a good method of countering XSS attacks, no matter how good these filters are.

So, no, I do not think ESAPI will make Symphony less vulnerable against XSS attacks, and investing time in an extension or integration in the core with that purpose is a waste of time better invested in other places.

...Mr. Dutchmen. You are so, just, wrong. There is no other way to put it. I am sorry to be blunt.

ESAPI will help with XSS-- it will help with a host of security issues outside of that scope as well.

As an added bonus, it was designed to be slapped on to extant projects. So, you have some reading to do. Or you could change your argument to, "I don't wanna do it." Either outcome is acceptable. But your current argument, it has to go.

If you choose to elevate yourself, I might recommend starting your reading here: https://www.owasp.org/index.php/XSS%28CrossSiteScripting%29PreventionCheatSheet

I'm gonna chalk this up to a bad week, spiked punch, or hidden agenda. Something unrelated to pooping on a really great security library and spewing lies (like that it won't help reduce XSS) for no valid reason.

I suggest to delete the above comment, since it's a violation of forum rule #1.