Changing the ColdFusion CFIDE Scripts Location

January 10, 2011

One of the things that the HackMyCF ColdFusion server security scanner looks for, is if the /CFIDE/scripts/ folder is in it's default location. There have been security vulnerabilities located in this folder in the past, most notably was the FCKEditor Vulnerability in ColdFusion 8.

Because it's really easy to change the default location of /CFIDE/scripts/, why not make a hackers life that much more difficult.

It's pretty easy to move it to a non-default location, because ColdFusion administrator has a setting called Default ScriptSrc Directory (located on the Settings page), by default it is set to /CFIDE/scripts/:

Default ScriptSrc Directory Screenshot from ColdFusion Administrator

We can come up with a totally new URI, and be creative, in this blog entry we'll use: /cfjs/ (be sure to pick something unique, and not already in use).

Setup a the virtual directory for your new URI

Your next step is to setup a virtual directory for your new ColdFusion Scripts directory /cfjs/. You also want to block access to /CFIDE/scripts/. I prefer not to actually move or rename the /CFIDE/scripts/ directory (I block it on the web server instead), this way we can ensure that any ColdFusion installer updates can still do their thing.

Using Apache with mod_alias

Most Apache web servers will have the mod_alias module enabled, so we can use that to setup the virtual directory for all websites, and also block requests to /CFIDE/scripts/. To do this add the following to the end of your httpd.conf file:

# Create a new Virtual Directory
Alias /cfjs /var/www/path/to/CFIDE/scripts

# Return 404 for all requests to /CFIDE/scripts
RedirectMatch 404 (?i)/CFIDE/scripts.*

Using IIS

If you are using IIS 7 or greater you can use the IIS Request Filtering to block access to /CFIDE/scripts/ after creating the necessary virtual directory by adding a sequence under the <denyUrlSequences> node (under the <requestFiltering> node) in the applicationHost.config file:

  <add sequence="/CFIDE/scripts"/>

If you want an even more secure approach (block more of the /CFIDE structure) then take a look at the ColdFusion 9 Lockdown Guide that I wrote for Adobe, it has more in depth examples for Apache and IIS 7.

Also consider that if you don't use any of the CFForm or ajax controls then you can simply block the entire /CFIDE/scripts/ directory all together, you don't need the virtual directory.

Related Entries

2 people found this page useful, what do you think?


Hey . . . theres'a missing closing "I" tag somewhere in the "Using Apache with mod_alias" section.
Fixed, thanks.
"...this way we can ensure that any ColdFusion installer updates can still do their thing."

Aw man, that one burned me a while back when I upgraded to 9.0.1. I totally forgot to copy over the cfjs directory after the update and I was so confused as to why I kept getting some really bizarre error messages.

Silly me.
If I copy the scripts folder to f:\cf-scripts, and set up a VDir called "CFIDE" to that folder on all IIS web sites, then change the setting in CFAdmin..... will future updates 'find' the f:\cf-scripts folder?

Or is it better to point the VDIR to the \CFIDE\scripts folder? (In conjunction with the other steps in the CF9 hardening document.)

@Rick - yes I would just create a vdir to the default location, and setup request filtering to block /CFIDE/scripts/

When you start copying CFIDE folders around it's easy to forget about them when it comes time for updates / patches.
What are the required permissions for that directory?
@Jim - on windows the /CFIDE/scripts/ needs Read permissions for the web server / app pool user. On linux you need rx permission on the directories and r permission on the files for the web server user.

There are some CFM files in /CFIDE/scripts if you want to allow their execution you can add the read permission for the CF user account for those files as well.
So, this virtual dir is exposed in the code when viewing source. Doesn't that defeat the purpose here or are we going with security by deception? I'm all for taking away defaults as a matter of practice, but want to make sure I'm not doing something wrong.
Mark - yes the path could still be found in the source code of a page that used one of the scripts in there. By changing the default location you could be spared from attack via a script kiddie, but probably not otherwise.
Thanks for these instructions (and the hardening guide). We have been implementing changes, but I wondered - is there an easy way to test if changes are working correctly? i.e. if /cfide/scripts is still exposed?
Paul, one way is to run your server against - this is our tool that will make lots of requests to your server and look for lots of CF specific vulnerabilities, including if /cfide/scripts is in the default location, and if you didn't lock down CF administrator properly, etc.

We also have paid plans that let you schedule scans on a daily, weekly, monthly, quarterly basis starting at $10/month. That way you can get notified if you do something on your server that opens it back up again.

Recent Entries


did you hack my cf?