Blog

23Jul
2008
Hacker Webzine Recommends Use Of CFQUERYPARAM

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.

Related Blog Entries

Comments (28)



  • Ray Majoran

    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

    #1Posted by Ray Majoran | Jul 23, 2008, 03:35 PM
  • Ben Forta

    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

    #2Posted by Ben Forta | Jul 23, 2008, 03:44 PM
  • Ray Majoran

    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

    #3Posted by Ray Majoran | Jul 23, 2008, 03:50 PM
  • Jared Rypka-Hauer

    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! ;)

    #4Posted by Jared Rypka-Hauer | Jul 23, 2008, 04:29 PM
  • mark kruger

    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.

  • magnus

    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.

    #6Posted by magnus | Jul 23, 2008, 05:28 PM
  • Ben Forta

    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

    #7Posted by Ben Forta | Jul 23, 2008, 06:11 PM
  • Chris Phillips

    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. :-)

  • Brad Wood

    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...

    #9Posted by Brad Wood | Jul 24, 2008, 03:42 AM
  • David Stockton

    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 :)

  • Matt Osbun

    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.

    #11Posted by Matt Osbun | Jul 24, 2008, 08:00 AM
  • Andrew Pritchard

    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.

    #12Posted by Andrew Pritchard | Jul 24, 2008, 08:06 AM
  • David Stockton

    @Andrew:

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

  • Jim Priest

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

  • Steve K.

    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.

    #15Posted by Steve K. | Jul 24, 2008, 09:51 AM
  • Dean Lawrence

    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?

  • Jared Rypka-Hauer

    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.

    #17Posted by Jared Rypka-Hauer | Jul 24, 2008, 01:31 PM
  • Ben Forta

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

    --- Ben

    #18Posted by Ben Forta | Jul 24, 2008, 01:34 PM
  • Dean Lawrence

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

    Thanks.

  • Andrew Pritchard

    Thank you, David Stockton.

    #20Posted by Andrew Pritchard | Jul 25, 2008, 07:36 AM
  • simplico

    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.

    #21Posted by simplico | Jul 25, 2008, 10:58 AM
  • Fred Wenger

    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.

    #22Posted by Fred Wenger | Aug 26, 2008, 12:04 PM
  • Ben Forta

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

    --- Ben

    #23Posted by Ben Forta | Aug 27, 2008, 04:50 AM
  • Mark

    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.

    #24Posted by Mark | Sep 21, 2008, 07:59 PM
  • Brad Wood

    @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#">))

    #25Posted by Brad Wood | Sep 22, 2008, 11:49 PM
  • Mitro

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

    #26Posted by Mitro | Feb 5, 2009, 10:15 AM
  • cleveland

    I would like to see too the NULL parameter in CFQUERYPARAM have an option like NULL=MAYBE.

    #27Posted by cleveland | Nov 20, 2009, 11:01 AM
  • Allan

    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.


    http://www.btscene.com

    #28Posted by Allan | Jul 23, 2010, 06:09 AM