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 resolves in the default location.
What is the cf_scripts directory for?
The cf_scripts directory holds various resources that are needed for ColdFusion tags that use UI. Most commonly these include javascript files or css files, but there are also CFML files in this directory.
When you use a cfform tag, ColdFusion will output a script tag which loads the file: /cf_scripts/scripts/cfform.js. The first part of that URI, /cf_scripts/scripts is configurable in the ColdFusion administrator in the Default ScriptSrc Directory setting.
Why is this important?
There have been security vulnerabilities in files located in this folder in the past, most notably was the FCKEditor Vulnerability in ColdFusion 8 which allowed files to be uploaded to your server.
By changing the default location of /CFIDE/scripts/ or/cf_scripts/scripts/ this can buy you a bit of time to install a patch if there is another vulnerability under these directories in the future.
Does the Default ScriptSrc Directory need to be exposed?
In many cases you do not even need to expose the /cf_scripts directory, you can instead just block it on your web server. This provides the best security because you have just reduced your attack surface.
You only need this URI exposed if you happen to use one of several tags that generate UI or use internal javascript.
Some of these tags include: cfform, cfdiv, cfajaxproxy, etc. I've gone through and documented which tags and features use the /cf_scripts files in section 12.1 Tags that use /cf_scripts/ assets of the ColdFusion 2023 Lockdown Guide.
It is important to note that the ColdFusion Administrator does use these tags and features, so you have to ensure that the Default ScriptSrc Directory is still accessible by your builtin web server (by creating a Tomcat virtual directory).
If you determine that you don't need to expose this directory you can go ahead and block /cf_scripts and /CFIDE on your web server. You can use Request Filtering on IIS to Deny the URI Sequence. If you simply block the URI, then you don't need to change the Default ScriptSrc Directory setting, or create the tomcat virtual directory.
How do I move it to a non-default location?
Locate the ColdFusion administrator setting called Default ScriptSrc Directory (on the Settings page), by default it is set to /cf_scripts/scripts on CF2016 and up (it will be set to /CFIDE/scripts/ on CF11 and below):
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/. The virtual directory will point to the physical path to the /cf_scripts/scripts folder in the wwwroot of your ColdFusion instance, eg: x:/cf/cfusion/wwwroot/cf_scripts/scripts
Next block access to /cf_scripts on your web server. Do not move or rename the /cf_scripts directory (block it on the web server instead), this way we can ensure that any ColdFusion updates can still update files within this directory as needed.
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 /cf_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/cf_scripts/scripts # Return 404 for all requests to /CFIDE/scripts RedirectMatch 404 (?i)/cf_scripts.*
Using IIS
If you have IIS Request Filtering installed you can use it to block access to/cf_scripts/ after creating the necessary virtual directory. In the IIS GUI:
- Click on the root server node (to apply to all web sites)
- Double Click on the Request Filtering Icon
- Click on the Deny URL Sequences tab
- Click Add URL Sequence
- Paste:
/cf_scriptsinto the text box and click ok.
Last but not least, create the tomcat virtual directory
Finally on CF10+ it is required to create a virtual directory on the Tomcat built-in web server if you changed the Default ScriptSrc Directory setting. If you skip this step certain parts of the CF admin might not work (typically the server update feature).
Here are the instructions for creating the virtual directory in Tomcat.
Comments
Hey . . . theres'a missing closing "I" tag somewhere in the "Using Apache with mod_alias" section.
Fixed, thanks.
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...
@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? Thanks!
@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 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.