ColdFusion - Basics of Security for ColdFusion v5

This comes from an answer to a thread on security on the Macromedia ColdFusion forums, in response to someone who was worried about a visitor to his website running their own code on his ColdFusion server, and discovering his administration password.

Point 1 below deals with his specific query, the other points deal with general actions you can take to make your ColdFusion server more secure. Please remember that good security is an on-running problem with any language / platform and that to be secure you have to keep up with patches and information about your products.

1. In order to get code on to your server, the attacker would have to upload it in some way. The most straightforward way of doing this is to post it through a form on your website which then displays what was posted, e.g. reviewing a forum posting or e-mail message before it is sent.

   Simple example:

   You have a form on your website asking for user feedback, it has two fields - one for their name, another for their comments. When someone clicks 'submit' their comment gets shown to them for review on the process page.

   So, to post the code: In to the comments box the attacker puts in the malicious CF code. When it gets posted to your processing page the page runs the code which has been posted, showing them something you don't want.

   To protect against this you can run some code to look for things you don't want being posted through your form (someone gave me part of this when I was worried about javascript being posted through). Something like this:

   <CFIF IsDefined("FORM.FieldNames")>
<CFSET isproblem = 'n'>

       <CFLOOP LIST="#FORM.FieldNames#" INDEX="ThisField">

           <CFIF FindNoCase('JAVASCRIPT','#Evaluate("FORM." & ThisField)#',1) OR FindOneOf("~##^}]{[|><", "#Evaluate("FORM." & ThisField)#", 1)>

           <CFSET isproblem = 'y'>

           </CFIF>
    </CFLOOP>

       <CFIF isproblem IS 'y'>
        <!--- Relocate to an error page, perhaps with a message (via URL flag) --->
        <CFLOCATION URL="/error.cfm">

       </CFIF>
</CFIF>

   If this script finds the word 'javascript' or any of the characters in the FindOneOf statement being posted through the form, it redirects the user to a page called 'error.cfm', which you can put a message on saying there is a problem with the form (it might be possible for people to trigger this by accident, so I'd go with a polite message.)

2. Take some basic security measures. Look in the security / sandbox settings and turn off tags you aren't using, such as CFRegistry, which would disable the code someone's posted here.

More general security measures:

3. Move CFAdministrator. You can move this directory (at least in CF5) without causing any trouble that I've come across. So rather than the default directory, which people can guess, move it somewhere obscure. If you are hosting the site yourself, create a site that can only be accessed internally and move CFAdministrator in to there. One of the places I worked at had a (very mild) attack where someone tried to access some of the Administration pages (they bounced off, but it was still a worry.) Moving the directory meant they wouldn't have any chance to access the pages, even if they did magically come up with the password.

   Note: If you do this you have to set the 'Unsecured Tags Directory' to be the physical location on the hard drive where the ColdFusion stuff is (at least in CF5.) If something goes wrong and it won't let you get to Administrator, follow the instructions at Max Fusion for turning CFRegistry back on.

   If you want to be sneaky you could replace the Administrator pages with something that looks identical but doesn't do anything. Personally I've got better stuff to do with my time, but if we had a load of people trying to access the Admin path I'd probably do this just to give them something to click around in.

4. Change the password regularly. Don't give the password to anyone who doesn't need it.

5. If you use tags like CFFILE, store the files that people upload in directories which are not accessible through the website (i.e. if your website is in a directory structure d:\inetpub\wwwroot\website, store the files in a new directory called d:\inetpub\websiteuploaded\ which means someone trying to run a file via your website can't, because it's not accessible via the web, only when you read it back using CF commands.

   This can be a hassle, especially if you're running a picture gallery or something, but you don't want to be storing executables for people.

   Also if you use CFFILE try to make sure no executables are uploaded. Be careful of Word docs and other Office files in case they contain macro viruses. Your server may not be affected, but your staff could be if they access the file, or it's given to a member of the public through the web.

This is by no means exhaustive, but it should give you some stuff to start with. Number 2 is a definite must, especially if you're not using the tags (if you have various developers, let everyone know which tags are disabled. If someone needs one turned on that can be dangerous (e.g. CFRegistry) you can look again at how to protect the server.

More code articles

Paul Silver. Original post: 9 August 2003, updated: 4 August 2004