Blog

25Apr
2014
GCN On ColdFusion And The Most Secure Programming Language

GCN has posted a story on the most secure web language based on data from WhiteHat Security in its 2014 Website Security Statistics Report. WhiteHat performed vulnerability assessments of more than 30,000 websites using .NET, Java, ASP, PHP, ColdFusion, and Perl.

I was pleased to see the summary that "Risk exposure does not vary widely between languages ... In fact, there was no statistical difference, in terms of the average number of vulnerabilities per slot, between any of the languages in this study." While I have not done the type of analysis performed here, instinctively I agree, the quality of the code written in any specific language has far more of an impact on security than does the language itself.

That said, a couple of interesting ColdFusion specific notes:

  • The research found far fewer instances of ColdFusion vulnerabilities than it did Java or ASP.NET, which makes perfect sense as there are far fewer ColdFusion servers and applications. That's definitely a Duh! finding.
  • When looking at "vulnerabilities per slot" (I'd like to better understand how that is defined and measured) ColdFusion ranked best, almost on par with Perl.
  • But when looking at SQL injection vulnerabilities, ColdFusion ranked worst. I'll go out on a limb here and suggest that this is probably a direct result of how easy ColdFusion makes database integration, and that simplicity often means that developers cut corners (or that less experienced developers end up writing production code).
  • But most important to me was the finding "that languages that have been around for decades were actually able to keep pace with more modern languages when it came to remediation of some vulnerability classes". As an example, "SQL injection had a 96 percent remediation rate in ColdFusion applications, and every single abuse of functionality vulnerability found in ColdFusion sites was remediated."

Hat tip: Randy Burton.

Comments (7)



  • larry c. lyons

    Also a possible reason why CF was ranked worse for SQL injection is that many developers still do not use CFQueryParam or sanitize their inputs before doing a query.

  • Ben Forta

    Complete agreement, Larry. That's part of what I meant by "less experienced developers end up writing production code".

    --- Ben

    #2Posted by Ben Forta | Apr 25, 2014, 03:26 PM
  • Mike Nimer

    SQL Injection - who remembers rainforestpuppy and the first sql hack? <cough>on my watch</cough>.

    After that hack was the PC Mag Article about sql injection and CF was the only language "NOT" mentioned because it had a way to prevent them, if developers used it. At the time, val() was enough to stop it. cfqueryparam was added later. And now it's listed as worse - that's messed up the function/tag are still there.

    #3Posted by Mike Nimer | Apr 25, 2014, 04:45 PM
  • Adam Cameron

    Hey Ben... what percentage of the values which should be passed as parameters are hard-coded into the SQL in the CFWACK? And this is how most people learn CFML...

    --
    Adam

  • Ben Forta

    Oh Adam, have a little faith in me. :-) In the very same CFWACK chapter that first introduces using CF variables in SQL (yes, simple and unsecured at first), there is a section entitled "Securing Dynamic SQL Statements" that starts with:

    "As you've just seen, the ability to create SQL statements dynamically using variables and more provides ColdFusion developers with incredible power and flexibility. But this power is not without risk, and before concluding this chapter we need to look at the very real danger of SQL injection attacks."

    The section then shows what SQL injection looks like, and then discusses variable checking and CFQUERYPARAM.

    #5Posted by Ben Forta | Apr 25, 2014, 06:23 PM
  • Adam Cameron

    Okey doke. I was just refreshing my memory with a quick google (of "coldfusion web application construction kit cfquery"), and was flicking through this: http://www.forta.com/books/0321515463/cfwack8-2-ec...

    I didn't look thoroughly/exhaustively, but every single one of the examples I scrolled past until I got bored (so perhaps the first dozen) had all their dynamic values hardcoded into the SQL. Including values straight from the URL.

    This sort of thing was also my (very rusty) recollection of back when I used the CFWACK for my own reference (say back in 2000-2003). So that's why I googled first to verify, before commenting.

    --
    Adam

  • Richfergus

    Oh Adam, leave Mr Forta alone.

    #7Posted by Richfergus | Apr 26, 2014, 12:00 AM