Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion, Adobe Flex

ColdFusion: Article

Ben Forta's ColdFusion Blog: SQL Injection Attacks, Easy To Prevent, But Apparently Still Ignored

SQL Injection Attacks, Easy To Prevent, But Apparently Still Ignored

SQL Injection Attacks, Easy To Prevent, But Apparently Still Ignored

I was just on a web site (no, not a ColdFusion powered site, and no I will not name names) browsing for specific content. The URLs used typical name=value query string conventions, and so I changed the value to jump to the page I wanted. And I made a typo and added a character to the numeric value. The result? An invalid SQL error message.

That's bad. Very very bad. It means that I was able to create a SQL statement that was submitted to the database for processing, a SQL statement that was passed to the database as is, unchecked.

You'd think that by now we'd have learned to lock down our code so as to prevent SQL injection attacks, but apparently this is not the case. You do not know what a SQL injection attack is? Well, read on.

Consider the following simple dynamic ColdFusion query:

SELECT *
FROM Customers
WHERE CustID=#URL.custid#
Here a WHERE clause is being populated dynamically using a URL parameter. This type of code is common and popular, and is often used in data drill-down interfaces. If the URL was:
the resulting SQL statement would be:
SELECT *
FROM Customers
WHERE CustID=100
But what if someone tampered with that URL so that it read:
Now the resulting SQL would be:
SELECT *
FROM Customers
WHERE CustID=100;
DELETE Customers
And depending on the DBMS being used, you could end up executing two statements – first the SELECT, and then DELETE Customers (which would promptly delete all data from the Customers table).

Scared? You should be. SQL statements are not just used for queries. They are also used by most DBMSs to create and drop tables, create user logins, change passwords, set security levels, manage scheduled events, even creating and dropping entire databases. And whatever features are supported by your DBMS may be accessible this way.

Before I go further I must point out that this is not a ColdFusion vulnerability at all. In fact, it is not even a bug or a hole. This is truly a feature – many DBMS do indeed allow queries to contain more than a single operation, this is legal and by design.

Of course, you should always be checking parameters anyway before passing them to your DBMS. Passing client supplied data (URL parameters, FORM fields, and even cookies) through unchecked is programmatic suicide. Attacks aside, it is flat out unsafe to ever assume that data submitted by a client can be used as is.

As such, you should already be using code like this:

<cfparam name="URL.CustID" type="integer">
This single line of code will lock SQL injection attacks out. How? Think about it, SQL injection (within ColdFusion apps) is really only an issue with non textual fields. If a text value is tampered with you'll end up with tampered text, but that text will all be part of the core string (within quotes) passed as a value, and will therefore not be executed as separate statements. Numbers, on the other hand, are not enclosed within quotes, and so extraneous text can be tampered with to create an additional SQL statement. And <cfparam> can protect you.

Of course, you may want more control, in which case you could use code like this:

<cfif IsDefined("URL.CustID")
and not IsNumeric(URL.CustID)>

… throw an error or something …
</cfif>

And as an additional line of defense you can use <cfqueryparam>, as seen here:

<cfquery ...>
SELECT *
FROM Customers
WHERE CustID=<cfqueryparam value="#URL.CustID#" cfsqltype="CF_SQL_INTEGER">
</cfquery>
If the previous tampered URL was passed to the this query, the value would be rejected and an error would be thrown. The CFSQLTYPE (aside from binding variables) performs data type validation checks, and values that do not match the type are rejected. That's it, only integers allowed, and malicious tampered URL parameters are not integers.

The bottom line is that SQL injection attacks have been around for as long as dynamic SQL itself. ColdFusion has made it incredibly easy to protect yourself against such attacks. Be it <cfparam> or <cfqueryparam> or your own conditional processing, it's simple to protect yourself, and your responsibility to do so.

If you have not been paying attention to this risk, stop whatever you are doing, fire up your IDE, and do a search for every single <cfquery> in your code. Then quickly scan to find any that contain #'s in them (that are not enclosed in quotes or passed to <cfqueryparam>), and make a list of the variables used. If any of them are URL parameters or FORM fields, create a <cfparam> for each (at the top of the page, or before the <cfquery>). It's that simple. Really. There is no legitimate reason not to protect yourself, so just do it. Now! And I mean right now, before you leave for the day or take off for the holidays, and despite whatever project you are working on or deadline you are up against. No excuses (and if your boss complains about you switching gears to take care of this one, send him my way!).

Enough said! (I hope).

 

More Stories By Ben Forta

Ben Forta is Adobe's Senior Technical Evangelist. In that capacity he spends a considerable amount of time talking and writing about Adobe products (with an emphasis on ColdFusion and Flex), and providing feedback to help shape the future direction of the products. By the way, if you are not yet a ColdFusion user, you should be. It is an incredible product, and is truly deserving of all the praise it has been receiving. In a prior life he was a ColdFusion customer (he wrote one of the first large high visibility web sites using the product) and was so impressed he ended up working for the company that created it (Allaire). Ben is also the author of books on ColdFusion, SQL, Windows 2000, JSP, WAP, Regular Expressions, and more. Before joining Adobe (well, Allaire actually, and then Macromedia and Allaire merged, and then Adobe bought Macromedia) he helped found a company called Car.com which provides automotive services (buy a car, sell a car, etc) over the Web. Car.com (including Stoneage) is one of the largest automotive web sites out there, was written entirely in ColdFusion, and is now owned by Auto-By-Tel.

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
pranny 03/24/09 08:59:59 AM EDT

I faced the same problem. Search for cfquery across all my apps. And i found billions of pages that need to be modified. I have a small script that helps in automating the process of applying CFQUERYPARAM. Of course, this script is a li'l specific to my need, but with a little modification, anyone can use it. The script is located at http://codecontrol.blogspot.com/2009/02/cfml-parser-in-python-part-2.html

Any suggestions/critism most welcome.

dskinkead 08/06/08 03:08:27 PM EDT

Good info, but I believe you are completely correct about textual data not being a threat.

Let's say you coded in a file named test.cfm:

SELECT * FROM sometable where field1 = '#preservesinglequotes(url.name)#'

Then a user put in this url:
http://yoursite.com/test.cfm?name=ttt';insert into sometable(field1,field2)values('xxx',99998);select * from sometable where field1='x

The result is sql injection. I have tested this and know it to be true. However this will only work if you use "Preservesinglequotes", which I have used many times. So we must protect ourselves even with textual data.

Luis Melo 07/24/08 10:34:54 AM EDT

Our system was not SQL Injection proof and we recently suffered an attack that corrupted the data in some of our database tables. The attack was quite elegant and fortunately did not cause severe damage other than the appending of a SCRIPT sting to a bunch of VARCHAR fields. This was meant to actually execute a JS file and this qualifies as a XSS attack.

In researching the Web for a solution for the problem, and a way to immunize our CF application against further attacks, we came across the CFQUERYPARAM solution, but our application has over 5000 files, each with one or more Queries and Stored Procedure calls. Implementing such a solution in such an extensive amount of files was impossible in a timely fashion, so I looked for another solution and came across a ColdFusion written function (isSqlInjection) that showed some promise but some shortcomings as well.

I wanted something that we could deploy fast and that would immunize the entire application in one single swoop.

As far as I understand, SQL injections can come from either FORM fields or from URL passed variables. Therefore we developed a function that was placed in our application.cfm and therefore used by all our CFM files. The function used a custom developed Regular Expression to check all URL and FORM fields for possible SQL Injections.

We were able to develop this in one day and implement it immediately. That same night we were able to catch and prevent 2 more SQL Injection attempts.
We have since improved the script and it now does the following:

• Checks all FORM and URL input for SQL injection code

• Interfaces (CFHTTP) with ARIN WHOIS Database Search (http://ws.arin.net/whois/) to get ISP information for the offender’s IP.

• Automatically sends an abuse report to the ISP concerning the attack.

• Displays a message informing the hacker that the attack was logged, that his/her ISP was contacted and that he/she is breaking the law

• Sends us an email with the SQL Injection string, IP address and other information.

• Stores the hacker’s IP address in an APPLICATION array (Black List).

o Each time a page in our application is requested, the IP address (CGI.REMOTE_ADDR) is compared with those in the Black List and if it is present, page execution is halted right at the application.cfm level returning a blank page to the browser

o Black List entries that are older than one hour are cleared by a scheduled task on an hourly basis.

We are making this code available to other CF developers for free. Please request a copy by email. [email protected].

If after receiving it you have suggestions or improvements, please send them my way as well.

Angela 04/24/08 06:09:38 PM EDT

Isn't WHERE id = #Val(url.id)# just as effective as using cfparam or cfqueryparam?

Will 06/17/06 02:53:03 PM EDT

Hi, I really enjoyed your article about injection attachs, but you forgot one small detial. Even if you use cfparam, it appears that you are still vuneralbe to injection attachs via forms. someone could fill a form filed with some thing like this

"# #drop table"

the first and last quotes seperate your statement from and move it ouside of the forms "quoes" and thene the the next two #'s creat and execute a new statement.

CFDJ News Desk 12/21/05 07:29:48 PM EST

Ben Forta's ColdFusion Blog: SQL Injection Attacks, Easy To Prevent, But Apparently Still Ignored. I was just on a web site (no, not a ColdFusion powered site, and no I will not name names) browsing for specific content. The URLs used typical name=value query string conventions, and so I changed the value to jump to the page I wanted. And I made a typo and added a character to the numeric value. The result? An invalid SQL error message.