This is an article I have done previously for HELM, I thought I may as well move it to my blog. I have removed any HELM specific stuff. The original post can be found HERE if you also want the additional HELM details.

If your running Coldfusion on your server you need to setup certain permissions and folders to have a secure CF installation.

Firstly in order for .cfm files to work, you need to make sure that coldfusion itself has the correct execute permissions.

PROTECTING THE CFADMINISTRATOR

I suggest that you turn off anonymous access on the web site that you have your coldfusion administrator on, or at least turn off anonymous access on the CFIDE folder. this means you need to login twice, once with a windows login, once with the CFADMIN login, or alternately restrict access by IP address.
If you do not do this, you get a lot of hack attempts on your CFIDE/Administrator folder and you give hackers access to certain files they ay be able to use to their advantage if your not secure.
You should also make sure you do not have the CFDOCS or sample applications installed on your live server.

RDS should also be disabled, but you can leave it enabled for your own use, if you have applied the above security.

CFIDE FOLDER

In order for certain java applet tags (cfgrid etc), classes, Coldfusion generated javascript (e.g. CFFORM) and flash forms to work, there has to be a virtual directory on each web site pointing to the CFIDE.

What you need to do is make another copy of the *original* CFIDE folder elsewhere (preferably in the folder where you store your web sites) and DELETE the ' administrator' and ' adminapi' folders from this copy.

Now use this version of the CFIDE when create the virtual directories for new web sites.

SECURING DANGEROUS TAGS

ColdFusion is NOT protected by the windows security or the IIS anonymous user permissions, if you have any of the dangerous tags enabled, customers will be able to read/write files anywhere on the server.
To avoid this problem and still give customers access to these tags you need the enterprise version of coldfusion so that you can deploy sandbox security. This will need to be manually setup for each web site. If you have the standard edition of CFMX you can only disable the tags globally. This version is therefore not really suited for shared hosting.

The following tags and functions should be disabled on a shared server. All these allow files to be read/written or both anywhere on the server.

• TAGS
  • CFFILE
  • CFDIRECTORY
  • CFEXECUTE (never enable)
  • CFCONTENT
  • CFHTTP
  • CFOBJECT
  • CFREGISTRY (never enable)
  • CFFTP
  • CFPOP
  • CFLDAP
  • CFMAIL ( this may also be an issue for you, as it allows customers to attach any file on the server to an email)
• FUNCTIONS
  • GetProfileString
  • SetProfileString
  • CreateObject
    
    the functions marked as "never enable" will not be affected with a security sandbox and should never be enabled on a live shared server.
    The other tags and functions you can enable in each customers sandbox and they will restrict file access to the root specified in the sandbox files/directories tab.

SANDBOX (cf enterprise edition only)

For each sandbox you setup, you need to add the following paths for each client in the files/dir's tab. Your paths may of course be different than below.
My examples presume a directory configuration thus:-

HomeDir (ftp root, non web accessible)
d:\wwwroot\mydomain.com\
Webroot
d:\wwwroot\mydomain.com\wwwroot

Sandbox paths

\ (e.g. d:\wwwroot\mydomain.com\)
\- (e.g. d:\wwwroot\mydomain.com\-)
NB: The following are for the temp folder to allow file uploads via forms, and to embed fonts using cfdocument
c:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\
c:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\-
c:\windows\fonts\

Correct the first two with the correct path to the clients FTP root (or web root if you do not have a
Correct the last two with the path to your coldfusion installation. These last two paths are required for file uploads to work as the cfusion temp folder is used. Make sure you use LOWER CASE drive letters.

SQL Server and MySQL databases should NOT have the username/password setup in the DATASOURCE in the CFADMIN, so will be safe as the customer only has this info and passes it in their code. If the customer asks for the username/password to be added in the datasource, then this is at their own risk as other clients will be able to run queries against their database if they know or guess the DSN.

On the CFTAGS and FUNCTIONS tabs, simply enable whichever tags and functions you want to allow, excluding the ones I told you to never enable
I suggest that you also do not enable CFOBJECT and CreateObject(java) by default, see Java security section below for why.

The Server/Ports tag should not need any changes.


JAVA SECURITY

Because ColdFusionMX is built on java and runs on a J2EE compliant server, JRUN by default there is absolutely no java security whatsoever from within CF. You customers can do just about anything they want via Java. Including Accessing the Java service factory, which allows them to manipulate all the CFADMINISTRATOR settings. You can even find documentation online how to do this.
Your customers will usually instantiate java classes using the CFOBJECT tag or the CREATEOBJECT(java) function, thus why I said do not enable these by default. Make your customers ask for it, and then ask them why they want it.
Unfortunately these 2 tags/functions are required by some people for CFC's, so some of your customers will need them.
Even without these tags/functions it is possible to instantiate and use java classes, but does require more java programming knowledge than most coldfusion developers are going to have.

CFOBJECT can also be used to call windows COMponents, so make sure you do not have anything installed they can take advantage of or at least have your server locked down with appropriate permissions.

Your only path for having a more secure CFMX is to run a separate instance of coldfusion for each site, which requires you to install the coldfusion for j2ee (multi server) configuration and not the standalone server configuration.
This of course is not very suitable for many sites it requires a lot of manual work plus a huge amount of memory on your server.

Another suggestion is to run the Coldfusion service as a separate user account with limited permissions rather than under the SYSTEM account which has full system access. The new user should only have access to Coldfusion installation itself, the webroot where your sites are located, and and other systems paths which are required, such a windows temp folder, fonts folder etc.

One other possibility is Blue Dragon from new Atlanta, which is another application server that supports the Coldfusion CFML language. You would still need a separate instance for each site, but the footprint is smaller, so is the price.

Hope this helps

Tip for running Coldfusion Professional more securely

If you cannot afford to run the enterprise version for the sandboxing facility, then here is another option.
As mentioned previously, Instead of running coldfusion under the System account, which is the default, create a custom windows user, and run coldfusion under this.

This will still allow customers to access each others files if you enable those dangerous tags, but at least will not give them access to your server and system files so that they can crash the server.

You can also replace the dangerous tags with your own custom tags as wrappers (as I used to do prior to CFMX). In your wrapper tags you call the original tags (as the custom tags folder will still have access to them) and pass the arguments, you can then control which paths they have access to.

If you've been on the fence about attending the day-long class Charlie Arehart is doing (on FusionDebug and FusionReactor), the day after the CFDevCon in London (and Munich), here's good news and even more reason it's a great value.

First, while the original offer was that attendees would get a free license for FusionDebug for attending (basically making the day of training free), some have asked if they could have FusionReactor instead. Since they're about the same price, Intergral has agreed that you can have a license to FusionReactor instead, if you'd like. Many thanks to them! This applies to both the Munich and London classes, and you can choose which you will have on the day.

Second, regarding the London class specifically, if you've not yet registered for the CFDevCon itself the day before, here's better news: those who sign up now will get a free ticket to the conference as well. (Sorry, no refund available if you've already purchased your ticket.)

That said, if you have any questions or concerns about these two offers, please direct them to David Tattersall.

Also if you plan to take advantage of the FREE ticket offer, please also register at CFDevCon so that I have your postal details.

The CF Meister himself, Ben Forta has today told me he will be able to make it to CFDevCon, which is great news as everybody likes to see Ben. He will be doing some sneak peeks of Scorpio and letting some other top secret stuff from the Adobe vaults out of the bag. This is now a total of 8 speakers and one totally packed day, not to mention the fun and games in the evening. So if you haven't aleady registered, better get over to www.cfdevcon.com and be quick as the addition of Ben Forta will prob have the tickets selling like hot cakes.

It has just been pointed out to me that I haven't even mentioned CFDevCon on my own blog, DOH! So I guess I should do so really seeing as I am the one organising it. As you probably know I run cfdeveloper.co.uk, and a few years ago I did a little CFDeveloper party, I had Hal Helms over to do a presentation on Fusebox, gave away a few prizes, and aferwards we free thinks provided by some nice ladies from a sponsoring recruitment agency. All in all it was a good time had by all and I had a really good turnout and a great response, but this was back in the Allaire day so there was more of a tight community back then. I did intend to start doing these events regularly, but never really got around to it. Anyway recently I got a little depressed about the fact that I could never afford the money or time to go to CFUnited, and thought that a lot of other people must have the same problem, so I thought I should revive the CFDeveloper party. Then I thought no sod it, we have nothing in this country except user gorups, so lets do a proper UK conference, and thus CFDevCon was born.

Not wanting to bite off more than I could chew seeing as I would be doing this all by myself and not knowing what kind of response I would get, I opted to just do a 1 day mini conference this year, with bigger plans for next year depending how it went. You can see the result at www.cfdevcon.com

I have been rather disapointed with the lack of sponsors and the lack of interest from Adobe, but so far it has just about managed to pay for itself. All things considered 100+ delegates for the first conference isn't all bad, I have been told thi is a good turnout, especially when you consider that Cfunited only had as many people on their first event, and the USA is a hell of a lot bigger than the UK. Hopefully everyone will have such a great time they will tell everyone else to come next year.

One thing I will say, organising and hosting a conference all by yourself is very hard work, and I probably wouldn't recommend as something to do just for kicks, so i'm actually quite chuffed I have pulled it off. Although setting the date in the same month my wife is due to give birth was not a good idea, so fingers crossed the little guy isn't going to pop out early.

I will post again after the conference and let you know how it went.

I recently posted the following on CFGURU and it was suggested that I blog it, so here it is.

When using the Sandbox Security in ColdFusion MX Enterprise Edition there are several things you need to take into consideration when securing your environment.

• You should have a default sandbox for the the folder that contains all your sites, with all tags/functions disabled that provide any kind of file system access
  E.G. d:\wwwroot
  You may also want to consider totally removing CFEXECUTE and CFREGISTRY form the server so that they cannot be used period. See my related blog entry for details on how to do this.
  The tags/Functions I disable by default are:-
  • CFFILE
  • CFDIRECTORY
  • CFREGISTRY
  • CFEXECUTE
  • CFPOP
  • CFMAIL
  • CFLDAP
  • CFCONTENT
  • CFDOCUMENT
  • CFFTP
  • CFHTTP
  • CFOBJECT
  • CreateObject() on CFMX6 and CreateObject(JAVA) on CFMX7
  • GetProfileString()
  • SetProfileString()
• For CFFILE uploads, every sandbox needs to explicity allow access to the temp folder
  E.G.
  C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\
  C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\-
  creating a default sandbox at the root of all your websites and giving that access to the temp folder does not work.
• The same applies to c:\windows\fonts folder when using cfdocument if you have specified ANY font name anywhere in the document then you need to have this path explicily allowed in the sandbox for that site.
• When using MYSQL DSN's, you sometimes need to explicity allow the IP:PORT of the MYSQL server in the sandbox. This is a random issue and does not occur all the time, so is perhaps a bug.
• Sandboxes do not apply when calling a CFC as a web service.
• Sometimes sandboxes just do not work, and you will need to delete it and re-create, sometimes more than once.
• Sometimes sandboxes become corrupted and will stop working, you must delete and re-create.
  A common error with corrupted sandboxes is that you will find that you can no longer enable sessions in your application.cfm, and you will get an access denied message for www.mydomain.com
• When CF tries to find a CFC in any custom tag path, it will fail with an "access denied" error for the custom tags path when you have sandboxes in place. CF will randomly try to find CFC's in custom tag paths if your not using a mapping to invoke your CFC or the CFC is not in the same folder as the calling template.
• Sandboxes do not work by default in a J2EE or multi-server install. You must explicitly enable them by modifying the jvm.config and ideally having a separate jvm.config for each instance otherwise you can only tell each instance to use the neo-security file for one particular instance. (see related blog entry)
• As you know CF will search all the way up to the directory tree for an application.cfm file, if you have an application.cfm above the folder that is sandboxed, it will not execute.
• If you call a custom tag in the custom tags folder, it will not obey the rules of the sandbox of the site that called it, I.E. it will have FULL access to all paths. (nb: this may have changed since CFMX 6)
• Sandboxes do not apply to CFX tags.
• Sandboxes to not apply to Java, if CreateObject(java) is enabled, you can do anything. even if CreateObject(java) is not enabled, you can create a JWS file and call it as a web service.