Question

How can one allow code snippets to be entered into an editor (as stackoverflow does) like FCKeditor or any other editor while preventing XSS, SQL injection, and related attacks.

Answer 1

Part of the problem here is that you want to allow certain kinds of HTML, right? Links for example. But you need to sanitize out just those HTML tags that might contain XSS attacks like script tags or for that matter even event handler attributes or an href or other attribute starting with ‘javascript:’. And so a complete answer to your question needs to be something more sophisticated than ‘replace special characters’ because that won’t allow links.

Preventing SQL injection may be somewhat dependent upon your platform choice. My preferred web platform has a built-in syntax for parameterizing queries that will mostly prevent SQL-Injection (called cfqueryparam). If you’re using PHP and MySQL there is a similar native mysql_escape() function. (I’m not sure the PHP function technically creates a parameterized query, but it’s worked well for me in preventing sql-injection attempts thus far since I’ve seen a few that were safely stored in the db.)

On the XSS protection, I used to use regular expressions to sanitize input for this kind of reason, but have since moved away from that method because of the difficulty involved in both allowing things like links while also removing the dangerous code. What I’ve moved to as an alternative is XSLT. Again, how you execute an XSL transformation may vary dependent upon your platform. I wrote an article for the ColdFusion Developer’s Journal a while ago about how to do this, which includes both a boilerplate XSL sheet you can use and shows how to make it work with CF using the native XmlTransform() function.

The reason why I’ve chosen to move to XSLT for this is two fold.

First validating that the input is well-formed XML eliminates the possibility of an XSS attack using certain string-concatenation tricks.

Second it’s then easier to manipulate the XHTML packet using XSL and XPath selectors than it is with regular expressions because they’re designed specifically to work with a structured XML document, compared to regular expressions which were designed for raw string-manipulation. So it’s a lot cleaner and easier, I’m less likely to make mistakes and if I do find that I’ve made a mistake, it’s easier to fix.

Also when I tested them I found that WYSIWYG editors like CKEditor (he removed the F) preserve well-formed XML, so you shouldn’t have to worry about that as a potential issue.