Over the last several weeks, ColdFusion web sites have been under attack all over the Internet.  In what is apparently the first large-scale automated SQL injection attack, what is assumed to be a botnet is attempting to use vulnerable sites to inject JavaScript code into the back-end database.  In this case, the attack is directed toward Microsoft SQL Server.  Once the JavaScript is injected, the hope is that the code from the database will be displayed somewhere on the web site, causing the visitor to download and execute the JavaScript code they had posted elsewhere on the Internet.

While this is all very unfortunate, it is entirely preventable.  If the web developer used proper secure coding techniques and considered the security implications of what they were doing, then of the many sites that were affected wouldn't be in the mess they're in now.  Fortunately this particular attack is easy to reverse within the database, and simple to prevent in the code.  Specifically, it exploits areas where the developer is assuming that the input from a URL variable will be safe to use and pass directly to the database query.  ColdFusion provides a tag called CFQUERYPARAM that tells the database to create and execute a "prepared statement" which negates the possibility of success in nearly all SQL injection attacks.  Unfortunately, many ColdFusion developers either don't know about this, or don't understand why it should be used.

On the CF-Talk mailing list there was a lot of discussion about this topic as the attacks began to infect more and more sites.  We all know that code can live on a site for years after it is written, and we can inherit code from other developers who don't know any better.  For them, it may take weeks, or even months, to go through their code and make the necessary updates.  In the mean time, their sites are sitting out there vulnerable to attack.  If you are in that position there are other preventative measures you can take:

1. Install a filter on your web server that performs URL rewriting.  This can look for specific keywords often used in these attacks (DECLARE and EXEC specifically for the current automated attack) and then rewrite or redirect and URL containing those keywords.  This prevents the attack from making it to your ColdFusion code at all.  Helicon makes an ISAPI filter for IIS called ISAPI_Rewrite that can do this on Windows servers.

2. Create a rule in your Intrusion Detection System that looks for and drops requests that contain the forbidden SQL keywords.  There are several custom Snort rules out there that will do this for you.

3. If you're on a shared server without access to these resources, you can implement code filters as well.  I wrote one back in late 2005 for a site I took over from another developer just after it launched.  Unfortunately the original developer had pretty much no concept of security, and I wrote several filters for it to hold us over until we had time to go back and clean up the code.  One of these was dubbed SQLPrev and has since been released into the public domain.  It can easily be included into any ColdFusion application to provide high-level protection from most SQL injection attacks.  The "official" ColdFusion MX code, as of this writing, can be found at http://www.gravityfree.com/_sqlprev.cfm.txt, and the ColdFusion 5 code can be found at http://www.gravityfree.com/_sqlprev5.cfm.txt.  I also maintain copies (MX, 5) here on my web site if the links above ever stop working.

I can't stress enough that these methods are not "full scale security" but rather a temporary perimeter filters to be used until your actual code is secure.  Someone once likened them to sentinels keeping watch at the city gates.  Just because the sentinels are there does not mean you shouldn't also lock the gates.