Andy asks:
What directories under CFIDE should be blocked/protected from public access on a public ColdFusion server? Is only preventing access to CFIDE/administrator good enough? How about CFIDE/adminapi? Any others that should be blocked? I tried searching the Adobe website, but I could only turn up a note regarding ColdFusion 4 and 4.5!
I'm pretty surprised by the fact that this hasn't been updated lately. I took a quick look at Livedocs, but didn't see anything that related to this.
I haven't done this myself in a while (I admit it - I'm lazy), but I'd think you would want to lock down these subfolders:
administrator
adminapi
classes (no need for folks to browse it)
componentutils
So I'm with you on administrator and adminapi. I mention classes and componentutils because there is no need for them to be visible anyway. But you can probablyg et away with just locking down the first two.
Any comments on this?
Archived Comments
I prefer the method of blocking the entire directory other than local IP addresses or some other method, then copying the necessary scripts somewhere onto the web root and creating a mapping to them. By default: deny all. Safest that way =)
Chris
CFMX 7 provides another alternative. In the Administrator, you can simply specify the 'scripts' directory (defaults to /CFIDE/scripts). This directory is used by the CFFORM tag to reference JavaScript for client side validation. Simply change that value to /_cf/scripts and copy the contents of the /CFIDE/scripts directory into that location in your doc root.
At this point, you can remove the web server mapping (or Virtual Directory) to /CFIDE. You can still access the Administrator on port 8300 (or whatever you have it set to).
If you're still running CFMX 6, 6.1 or CF 5, then you can just copy the /CFIDE/scripts folder to the doc root and then eliminate the web server mapping.
Yet another method:
You can also disable the built-in JRun web server, and set up another virtual host that accepts requests on some odd port (like 8300, 8080, or whatever you want). This 'new' web server is connected to the JRun proxy port and has a mapping for /CFIDE. Then, you can use web server authentication or IP restrictions to restrict access to your CF Admin pages.
Finally, if you have any firewalls or proxies between your web servers and your clients, you can use rules in those devices to restrict access to only internal IPs.
We basically put CFIDE under the default website and make it available only from localhost and the internal network IP. Unless I'm mistaken people will never be able to hit it unless they're on the VPN.
Good post and good comments. I'll be sure to point people in this direction when the question comes up.
@Damon - Nice one. I wonder if Charlie is covering this in his hidden gems class.
like Joe said, putting cfide on its own site and limiting it to a non-routable ip (i.e. localhost or 127.0.0.1) is one of the first steps to locking it down imho.
but how would that affect applications that use flash forms, flash remoting, etc.