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.

Views: 7012