Pete Freitag Pete Freitag

Changing the ColdFusion CFIDE Scripts Location

coldfusion

One of the things that the HackMyCF ColdFusion server security scanner looks for, is if the /CFIDE/scripts/ (for CF11 and below) or /cf_scripts/scripts/ (for CF2016+) folders 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/ or/cf_scripts/scripts/, why not make a hackers life that much more difficult?

Do I even need /CFIDE/scripts/ or /cf_scripts?

You may not! In that case you can just block it on your web server. This provides the best security because you have just reduced your attack surface.

If you happen to use one of several tags that generate UI or use internal javascript, then you may not be able to block it. Some of these tags include: cfform, cfdiv, cfajaxproxy, etc.

How do I move it to a non-default location?

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/ on CF11 and below or /cf_scripts/scripts on CF2016 and up:

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:

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

For CF10+ you will also need to create a virtual directory on the Tomcat built-in web server if you use it to access the ColdFusion Administrator. If you don't certain parts of the CF admin might not work (typically the server update feature

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.


Like this? Follow me ↯

Changing the ColdFusion CFIDE Scripts Location was first published on January 10, 2011.

If you like reading about coldfusion, security, cfide, iis, or apache then you might also like:

FuseGuard Web App Firewall for ColdFusion

The FuseGuard Web Application Firewall for ColdFusion & CFML is a high performance, customizable engine that blocks various attacks against your ColdFusion applications.

Comments

Hey . . . theres'a missing closing "I" tag somewhere in the "Using Apache with mod_alias" section.
by Lola LB on 01/10/2011 at 12:33:04 PM UTC
Fixed, thanks.
by Pete Freitag on 01/10/2011 at 12:44:18 PM UTC
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.)

Thanks...
by Rick on 01/09/2012 at 6:15:22 PM UTC
@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.
by Pete Freitag on 01/09/2012 at 10:13:19 PM UTC
What are the required permissions for that directory?
Thanks!
by Jim on 10/06/2012 at 5:23:59 PM UTC
@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.
by Pete Freitag on 10/08/2012 at 12:24:44 PM UTC
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.
by Mark on 01/07/2013 at 5:05:31 PM UTC
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.
by Pete Freitag on 01/07/2013 at 5:09:16 PM UTC
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?
by Paul on 03/07/2013 at 12:21:28 AM UTC
Paul, one way is to run your server against http://hackmycf.com/ - 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.
by Pete Freitag on 03/07/2013 at 11:23:05 AM UTC