Forta.com - Blog

I've been debating posting this for the past few days. But, as it does not really disclose anything more than has been publicly discussed as of late (on this blog and elsewhere), and as it actually makes useful suggestions pertaining to securing ColdFusion (specifically from SQL injection attacks), here goes ...

Last week 0x000000 # The Hacker Webzine posted an entry entitled Attacking ColdFusion. The post primarily describes SQL injection attacks, and explains the danger inherent in not using <CFQUERYPARAM>, and also shows the right way to use the tag. It also notes:

The cfqueryparam is generally secure because it utilizes a prepared statement, that is always binded as a string, which in term is nearly not exploitable. But, many ColdFusion applications do not use the cfqueryparam mainly because developers do not know about this, and also because this feature came only in to being, with later versions of ColdFusion.

I strongly recommend that you read this post, if for no other reason then to reinforce the reality that this risk is publicly known and being exploited, and to remind yourself (and your managers, coworkers, clients, etc.) that you must address this potential vulnerability immediately!

The 0x000000 post was also referred to yesterday by ScanSafe STAT Blog in an entry which notes that monitoring in recent days indicates that ColdFusion is now the target of an attack that had been previously targeting SQL Server powered ASP sites.

Comments

[Add Comment] [Subscribe to Comments]

I love how this article was posted on July 12, and since then, I have heard from countless people about CF getting attacked. It's like fuel for the fire.

Ray

# Posted By Ray Majoran | 7/23/08 3:35 PM

Ray, exactly, which is why I was so torn about posting the link. I have no doubt that this article contributed to the recent wave of attacks. But, now that it is out there, and has been linked to already by other sites, and is even showing up in Google searches ... well, it's time to make sure that the CF community knows what their potential attackers know.

--- Ben

# Posted By Ben Forta | 7/23/08 3:44 PM

I totally agree, and to be completely honest, I would consider the recent string of attacks a stern warning. The script that has been referred to by numerous people (that CASTS an update to each table) is a mere inconvenience. The script could have done MUCH worse than appending data to a field in a table.

I think this is a good wake up call for all CF developers to stop writing hack code and start paying attention to security. I know we got a good kick in the butt from this.

Ray

# Posted By Ray Majoran | 7/23/08 3:50 PM

I think this is really significant, in that something that's common enough to have the hacker community discussing it and actually publishing information on attack vectors has pretty much "arrived". It's also cool that they've confirmed the fact that CF is fundamentally a secure platform and that cfqueryparam works!

I think it's awesome... now, it's high time the CF community grows up and starts doing things right! ;)

# Posted By Jared Rypka-Hauer | 7/23/08 4:29 PM

Ben, I love what the author says of the CF error information - "I have never seen so much useful information in an error message" or something like that. That's one of those things that is often forgotten needlessly - adding cferror and turning down the robust debug info.

# Posted By mark kruger | 7/23/08 4:38 PM

Is there any reason that CFQUERY couldn't automatically bind cf provided variables in future versions of Coldfusion? Guessing datatypes might be an issue but is that needed to get a benefit. Does the binded (bound?) variable need to be typed for the DB server?

If backwards compatibility is a problem (particularly if datatypes need to be guessed) is an issue, it might be possible to have a setting in the Admin to control how strictly the binding of variables is handed.

# Posted By magnus | 7/23/08 5:28 PM

Magnus,

That's a pretty tricky one. There are assumptions that would have to be made, and a chance of making incorrect ones - there is always a risk. We've looked at it before, and I am sure we'll do so again.

--- Ben

# Posted By Ben Forta | 7/23/08 6:11 PM

Ben & Magnus,

Adobe could always add it as a setting. Then developers could turn it on. And if it did assume incorrectly and caused an error, they would have the opportunity to go put a cfqueryparam where it should have been in the first place. :-)

# Posted By Chris Phillips | 7/23/08 8:51 PM

The main problem with forcing the parameterization is people still do a lot of dynamic SQL where the table names, columns names, or order by clauses all come from a variable. There is really no safe way to do that unless you very sure those variables are coming from a trustworthy place.

We are afforded an awesome flexibility with cfquery and preservesinglequotes(), but with great flexibility come great responsibility...

# Posted By Brad Wood | 7/24/08 3:42 AM

We have been seeing a noticeable increase in attempted SQL Injection attacks on our clients' systems over recent months.

You definitely did the right thing posting this; the more awareness we can raise the better.

If you're worried about this type of attack or have already been effected by this or other issues then obviously, Intergral (the nice people behind FusionReactor) are available to help you :)

# Posted By David Stockton | 7/24/08 6:21 AM

Seems the big takeaway is that ColdFusion can't save you from ignoring good practices. No surprise there.

If you don't secure access to your CF Administrator, if you don't use CFQueryParam, if you decide to use PreserveSingleQuotes(), if you don't turn off robust error messages in production, then you are at risk.

# Posted By Matt Osbun | 7/24/08 8:00 AM

I would like to see the NULL parameter in CFQUERYPARAM have an option like NULL=MAYBE. If the value contained an empty string, the null value would be sent otherwise the value would be sent. It would eliminate a lot of CFIF statements.

# Posted By Andrew Pritchard | 7/24/08 8:06 AM

@Andrew:

You can get this functionality with this:
<cfqueryparam cfsqltype="cf_sql_varchar" null="#len(myArg) eq 0#" value="#myArg#" />

# Posted By David Stockton | 7/24/08 8:28 AM

Maybe it's time for another "ColdFusion Is Dead" round of blog posts... :)

# Posted By Jim Priest | 7/24/08 9:14 AM

As much of a negative impact that there has been recently with this wave of attacks on CF applications, it certainly can bring a positive aspect as well. Our organization has recently started to reevaluate ALL of our security practices as a result.

This should be a call to all of us to strive towards better practices when developing applications, and help keep fresh in our mind that we always need to keep a step ahead when it comes to application security.

# Posted By Steve K. | 7/24/08 9:51 AM

Ben,

Would selecting only "SELECT", "INSERT", "UPDATE", "DELETE" and "Stored Procedures" in the "Allowed SQL" option of your data source configuration in the CF Admin stop these attached as well?

# Posted By Dean Lawrence | 7/24/08 1:26 PM

No, Dean, because a lot of SQL injection attacks occur in SELECT, INSERT, UPDATE, and DELETE queries... they're a matter of not properly validating and escaping your SQL, not due to any particular sort of query or command.

# Posted By Jared Rypka-Hauer | 7/24/08 1:31 PM

Dean, no, because a statement starting with SELECT could end with one of these attacks.

--- Ben

# Posted By Ben Forta | 7/24/08 1:34 PM

Gotcha, so CF is only seeing the initial command and not the additional ones added to the string.

Thanks.

# Posted By Dean Lawrence | 7/24/08 1:38 PM

Thank you, David Stockton.

# Posted By Andrew Pritchard | 7/25/08 7:36 AM

I agree with Mark K. Always use cfqueryparam, configure cferror, and use val() as well. It's sad seeing so many live sites using the default error template. tsk, tsk. Things like these shouldn't be left out in any CF books.

# Posted By simplico | 7/25/08 10:58 AM

We are in the same boat as Brad. We like to be able to re-use code, so we use the same query code to run slightly different queries and to keep it cleaner we put the logic in a separate place and send it to CFQUERY as a variable. It would be GREAT (version 9!?!?) if we could embed CFQUERYPARAM in a string variable somehow or have some way to make it possible to use a variable in a query and still be able to CFQUERYPARAM it.

# Posted By Fred Wenger | 8/26/08 12:04 PM

Fred, I am hoping that CF9 does indeed allow that, but no promises yet.

--- Ben

# Posted By Ben Forta | 8/27/08 4:50 AM

How would you properly use cfqueryparam with instr()? We have a field that stores a list of values in single quotes such as TypeID may contain: '1','22','34','101'

In our query we use:
AND (InStr(TypeID,'''#id#'''))

Since ID is a text variable, how would you recommend we properly secure it. Or, is this a potential security threat.

I realize there may have been a better way to write this, but at the time of creation 7 years ago and less experience, that is how it was written.

# Posted By Mark | 9/21/08 7:59 PM

@Mark: For future reference, questions like this would be a very good candidate for a mailing list such as the one found at: http://www.houseoffusion.com/groups/cf-talk/

In answer to your question, the InStr() function expects nothign more than a string as the second input. Therefore the usage of cfqueryparam here should be no different than any other string which is a parameter in a query.

AND (InStr(TypeID,<cfqueryparam value="#id#">))

# Posted By Brad Wood | 9/22/08 11:49 PM

At http://rapid4me.com/ have found lots of similar articles on this and other topics. Sometimes they even frighten me...

# Posted By Mitro | 2/5/09 10:15 AM

[Add Comment]

Hacker Webzine Recommends Use Of CFQUERYPARAM