Show #212: Playing the Blame Game

ColdFusion , Security , Railo , HackMyCF , Adobe Add comments

This week Scott and Dave get into the "Blame Game", the recent debate over who is most responsible for ColdFusion sites that get hacked well after the patches were released by Adobe.  Scott updates us on his golf league website and its switch to Railo. The guys discuss Mailinator and the fun process of generating unique email addresses for sites requiring an email address. And what episode of CFHour wouldn't be complete without discussing yet another bad Stack Overflow answer, this one having to do with including headers and footers.

Show Link:





A little bit about our sponsor. Host Media is, among other things, a ColdFusion hosting provider. Click the link below for an exclusive discount for CFHour listeners using the discount code 'cfhour'

Host Media


Show Topic Links:

ColdFusion Fail?

ColdFusion 10 Lockdown Guide

ColdFusion 9 Lockdown Guide

Who’s at fault

Forta chimes in


Why would you suggest this as a solution?


Buy Stuff


CFHour intro and outro audio created and provided by vocal talent James Allen:

9 responses to “Show #212: Playing the Blame Game”

  1. David Epler Says:
    There was no lockdown guide per se for ColdFusion 8, but there was a ColdFusion 8 developer security guidelines document (October 2007), , where on page 30 it states to restrict access to CFIDE/adminapi, CFIDE/administrator, CFIDE/componentutils, and CFIDE/wizards

    100% agree that all content of /CFIDE should not be encrypted.

    Also wrote up long piece on how there was enough fail to go around, , which shows how everyone that touches a ColdFusion install has responsibility for security.
  2. Brad Wood Says:
    Here's the link on Twitter where the @coldfusion account said they contact "support customers". I took that to mean they only contacted specific customers who are in a support contract with them. I don't know if that's the case or not though.
  3. Scott Stroz Says:
    Brad - if they only reach out to 'support customers' that makes it worse. As if Adobe only cares about those who pay extra for 'support'. Security fixes are NOT something that you should have to pay for, especially after shelling out several thousand dollars to begin with.
  4. Adam Cameron Says:
    Guys, another good podcast.

    Dave... your (or it was Scott, really) explanation as to how your not an apologist basically cements my opinion that you are. You're just in denial about it. That you diss CF in private but offer a second face in public? Not cool. And not helpful. And is the behaviour of an apologist. But... [shrug].

    I've also downvoted that answer on StackOverflow. I think as well as downvoting things though, you should both add a comment explaining why. Otherwise it's not as helpful as it could be.

    I've raised a bug for the /CFIDE thing... to get the JS/CSS stuff moved to a different location. Maybe you would like to raise a ticket to get the files unencrypted? Talking about it on the podcast is good for discussion, but if you want something done, you need to get it in front of Adobe (and hopefully encourage people to vote for it).

    The ticket number for my one is https: //

    Nice one guys.

  5. Adam Cameron Says:
    Once again: your spam trap is too vigorous... it decided that because I had a URL in my comment, it was unacceptable because it MUST be spam. Which is daft.

    Does this software not have a moderation queue or something? Or the ability to whitelist users? Perhaps if not, you could look at using Disqus instead of the native commenting system, as Disqus takes care of all of this for you.

  6. Michael Zock Says:
    Be sure to submit detailed JIRA tickets for your ORM problems so the Railo dev team has enough information to work on a solution.

    For example, when I tried to enable the ORM secondary cache in Railo there was an annoying bug that has since been fixed (, but after the fix another problem popped up that means it's still unusable on some systems ( Probably something environment-related, since the first bugfix seems to have been enough to solve the problem on Micha's system.

    Oh, and Citroën is a French company, but the target in question was one of their websites for the German market. ;)
  7. Sean Corfield Says:
    I was interested in your Railo startup time comments Scott. I strongly suspect you're seeing the ORM startup overhead and I suspect the reason there's a difference between reported startup times is due to CF10 automatically starting all its secondary modules in the background as soon as it is "up", whereas Railo starts them on demand (i.e., after the basic server is "up").

    I suggest that because I don't use the ORM (don't get me started on what I think about ORMs in general and CFML's ORM in particular! :) so if your first request is a "regular" app's page (no ORM etc), I think you'll find Railo serves it up pretty much instantly after it reports the server is "ready".

    No big deal, as you say, but just wanted to put that out there as a possible explanation.
  8. Scott Stroz Says:
    Sean - I assumed the ORM 'spin up' had something to do with it, however, there are times when I start up (or reboot) Railo locally and don't try to refresh a page right away (usually, I get distracted) and after a few minutes I will refresh the page and it comes up pretty quick - even faster than the initial 'spin up' on CF10.

    Also, keep in mind, I have done no formal testing to time it, going more on perception than anything else. I would still give the edge to Railo in 'total times from start up to app ready', but I just do not think it is as fast as some make it out to be - mileage may vary, of course.
  9. Sean Corfield Says:
    Interesting... Sounds like both are trying to spin up some stuff in the background post-startup then. I know Adobe did a lot to address startup times in CF10(?) by moving stuff to the background but I haven't dug into how Railo works in that area (and we have so much other stuff that affects startup speed, such as New Relic agent instrumentation and the initial compile-on-demand Clojure load that it's kind of irrelevant for us - we have to "warm up" our apps before they go into the cluster anyway).

    It's good to hear your experiences with Railo - good and bad - and it's entertaining to hear Dave just utter a non-committal "Nice." in response to pretty much anything you praise about Railo :)

Leave a Reply

Leave this field empty:

Powered by Mango Blog. Design and Icons by N.Design Studio