Blog

14Jan
2013
Is It Safe To Block Access To /cfide?

A user, worried about the recent attacks on ColdFusion servers, asked if he could safely block all public access to /cfide. My response to him was the following:

The short answer is "yes, if ..."

There are quite a few ColdFusion features that use files and URLs within /cfide, these include:

  • <cfform> and supporting tags and features
  • Charting
  • Java applets (which you should not be using anyway)
  • AIR synchronization
  • Admin API
  • And more

Oh, and then there is the biggie, ColdFusion Administrator itself.

So, can you block /cfide? If you are not using any of these features, then you can indeed create a separate locked down web site just for ColdFusion Administrator and then block all public access to /cfide. If you are using these features, then you will need to block with greater granularity and specificity so as to not break your sites and apps.

(In my opinion, this is yet another reason to use 3rd party UI and form and charting options, but that's a separate discussion).

Check out Pete Freitag's critically important Adobe ColdFusion 10 Server Lockdown Guide for all the detail and step-by-step instructions you'll need to secure your ColdFusion server. Pay special attention to the technique used to move ColdFusion Administrator to an isolated locked down non-public web site.

Related Blog Entries

Comments (6)



  • Rick Smith

    I hadn't ever actually considered blocking the whole directory, and currently can't because a number of clientele are using cfforms, etc. But I'm thinking this is probably the route to take anyhow. With jQuery form validation and the number of quality charting utilities available I guess it's not really necessary. Thanks Ben!

  • Adam Tuttle

    Typo: You wrote < cform >, meant: < cfform > :)

  • Ben Forta

    Oops, good catch. Shows how often I use that tag, huh?

    #3Posted by Ben Forta | Jan 15, 2013, 11:13 AM
  • Pete Freitag

    Just wanted to point out that you can actually change the location of /CFIDE/scripts in the ColdFusion Administrator to be /something-else/ and still use cfform or other tags, see my blog entry here which describes how to do it: http://www.petefreitag.com/item/774.cfm

    Ofcourse blocking /CFIDE all together is the best bet (if you can), there have been vulnerabilities under the /CFIDE/scripts uri as well.

  • Scott D.

    We use a different method for blocking access to CFIDE while still allowing tags that require scripts to run. These instructions are for IIS.

    1) Create a new website titled CFIDE (Typically we use the webserver root for the home directory). We also set the access port to 8007 and lock down the website by IP.

    2) Move CFIDE into that new websites directory

    3) Create virtual directories in your websites main folder for Scripts and Classes pointing back @ the actual directories in the new location of CFIDE.

    That's it. CF server can still access the required files, and you can still access CFADMIN (http://www.yoururl.com:8007/CFIDE/administrator/in...)

    I hope this is understandable. If anyone is confused, and wants to use this method, feel free to email me.

    -Scott

    #5Posted by Scott D. | Jan 30, 2013, 03:27 PM
  • Ben Forta

    Yep, that works. Actually, it's similar to the recommendation in the ColdFusion Lockdown Guide which sets up a dedicated web server instance for cfide that only accepts requests from locahost.

    #6Posted by Ben Forta | Jan 30, 2013, 03:30 PM