home Links Articles Books Past Meetings Photos SiteMap
The MDCFUG is sponsored by TeraTech. Visit us at www.TeraTech.com

Please send
comments/questions to

michael@
teratech.com

 

CPCUG Monitor

 

Securing your ColdFusion Server

by Michael Smith and David Schroeder

TeraTech http://www.teratech.com/

Security in ColdFusion

In this article we focus on what ColdFusion security is and what steps you can take to secure your ColdFusion Server.  Utilizing these relatively simple methods can make your ColdFusion Server a far more secure machine.

 

If you are not already familiar with Allaire's ColdFusion, it is a tag-based markup language (building on HTML, or Hyper-Text Markup Language) that is used to write dynamic web pages.  ColdFusion is currently on version 4.51, with versions for Windows NT, 95, 98, Linux, and Solaris.

 

Securing a ColdFusion Server must address three main issues; first you should secure the non-ColdFusion systems such as the Operating System and the Network connection, second you should secure the ColdFusion Server software, and lastly you should address security within the ColdFusion code that runs on the Server.  Particularly of issue is the security of the ColdFusion Server software, the configuration of ColdFusion Server is critical to the security as a whole. Here are some simple steps you can take to improve security right away.

Secure ColdFusion Server Configuration

 

Here are some tips for securing your databases. To better isolate your machine from security hazards, store your databases in separate directories from the root directory of your web server, on separate drive, or if possible on a separate machine. Move your databases from Microsoft Access to the latest version Microsoft SQL Server or Oracle, which are more secure and has far better security features than Access.  Access is known to be unreliable under load, particularly with ODBC connectivity.   If you must use Access, configure it in ColdFusion Administrator to run with OLE Database drivers instead of the standard ODBC drivers.  OLE Database drivers will require the latest Windows Database driver updates to your system (such as MDAC drivers).  If you use SQL Server, use User IDs and passwords that are difficult to guess, avoid short or common words.   Delete the guest and sa UserIDs from SQL server, which are default accounts on SQL server.

 

Install and run only those services and applications you absolutely need on your ColdFusion Server, unnecessary applications could potentially pose security risks and hurt performance. Turn off or disable ColdFusion's RDS Service, which could also be a large security risk. Remove any unused Custom Tags, such as CFX and CF tags, they potentially present a security risk through misuse. If there are no HTML only (non-ColdFusion) files in your directory, turn off read access and only leave on execute access to the directory. Maintain a log of all IP addresses and other pertinent information on each page access using the CGI.REMOTE_ADDR and CGI.HTTP_HOST variables.  Logging detailed activity allows you to roughly backtrack through a given user's activity on your site.  If you are using Windows NT, create a new Administrator account under a less common name instead of the guest and administrator accounts.

 

Having a secure Administrator account is probably one of the most important issues covered in this article.  Only give the access rights for read/update/delete, etc. that your application absolutely needs in SQL server.  Prevent sensitive data from being accidentally exposed by using Stored procedures in SQL Server and Oracle.   CFTRANSACTION prevents complex database operations from only partially completing when an error occurs.  Either use CFLOCK for read and write access of Application and Session variables, or globally restrict all access to these variables to single threads in ColdFusion Administrator. Remove the /CFDOCS/ directory that contains potentially dangerous example code.

 

Turn off unnecessary tags in the ColdFusion Administrator, such as CFDIRECTORY, CFFILE, CFCONTENT, CFOBJECT, if you are indeed not using them.  Generally the tags that can be disabled in the Administrator are potentially dangerous to your server if exploited, for example unauthorized use of the CFFILE tag could allow access to any file on the server. Unused datasources from ColdFusion Administrator should also be removed.  Do not save sensitive User IDs and passwords in ODBC datasource settings in Administrator, instead use CFINCLUDE in code and encrypt your code so that passwords cannot easily be exposed.

 

Although ColdFusion provides Basic and Advanced Security facilities to prevent unauthorized use of ColdFusion Administrator, Allaire strongly suggests two ways to secure access to the Administrator at the file level. Use your Web Server’s file security to protect the ColdFusion Administrator directory from outside web access. To do this, edit your Web Server configuration to limit access to the directory /CFIDE/ADMINISTRATOR from the web to those IP addresses that should have access. Additionally, removing the directory from the web server when ColdFusion Administrator is not in use can better ensure security.

 

Instability may occur unless named CFLOCKs are around reads and writes for sessions and applications.  Browsers retrieve pages with four to eight simultaneous threads, and it is possible for two or more templates to try to write to the same user's session variables.  To avoid performance issues stemming from the use of the locks, name the locks by concatenating the CFID and CFTOKEN values, thereby single-threading access to those variables only for the one user in the one browser. Encrypt your ColdFusion source code files (but save a backup copy first, just in case!) using CFCRYPT.EXE located in the /CFUSION/BIN directory.  Bear in mind that no encryption is totally secure, but that encrypting source code adds an extra line of defense.  If you use ColdFusion Studio 4 or above, when you upload a project it can encrypt your CF pages as it up loads them - this avoids the problem of accidentally encrypting your only copy of the source code! For pages that handle form submissions, test that the variable CGI.HTTP_REFERER really contains the URL that you think it was submitted from, helping to prevent people submitting outside form data. For example, the following code checks for the CGI.HTTP_REFERER to contain the correct value:

 

<CFIF NOT CGI.HTTP_REFERER CONTAINS "the_correct_page.cfm">

  <CFLOCATION URL="back_to_login_page.cfm">

  <CFABORT>

</CFIF>

 

Regularly apply all the latest security fixes to Windows NT or Linux/Solaris and your Web Server software, new patches and fixes are released on an almost daily basis. In the case of passing numeric variables via URL, use val() to ensure that all you get is a number. This prevents people adding SQL to the end of your URL variable, for example:

 

http://myserver/page.cfm?ID_VAR=7%20DELETE%20FROM%20MyCustomerTable

 

In the case of passing text variables, enclose them in single quotes and do a check for single quotes in the URL variable and generating an error message if found.  Use Apache, Internet Information Server, or O'Reilly WebSite directory security, possibly with CFAuth too.  Use a login form with the session.authorized variable in header as below to restrict access from outside your intranet, that way you set the session variable in a login page or other authorization mechanism and validate in your header that it is properly defined.  For example, this would go in your application.cfm or header.cfm, checking for your IP Address or session variable:

 

<CFSET page = "#cgi.script_name#">

<CFIF page contains "/intranet">

      <CFIF left(CGI.REMOTE_ADDR,10) IS NOT "123.456.789">

      <!--- your subnet mask --->

            <CFIF not isdefined("session.authorized")>

                  Sorry, you must login first. 

<!--- message in case CFLOCATION fails --->

<CFLOCATION URL="http://123.456.789.1/login.cfm">

<CFABORT>

            <CFELSE>

                  <CFSET session.authorized = TRUE>

            </CFIF>

      </CFIF>

 

Your protected links here.

 

</CFIF>

Handling Errors properly

Handling ColdFusion errors in a discrete way is another trick to better security for your ColdFusion Server.  Good error handling allows you to control what is displayed to your users and how an application reacts to an error.  Make sure you restrict debugging information to only the IP Addresses that absolutely require it, and when working in a production environment, turn off debugging entirely.   Debugging information displayed to the end browser exposes potentially sensitive information, such as the names of SQL databases and server information.  Record unexpected or uncommon errors to a custom log file you create.  For example:

<CFSET LogFile = "d:\website\htdocs\logs\cferror.log">

<CFFILE action="APPEND"

      file="#LogFile#"

      output="The XXXXX error occurred at #now()#">

 

Furthermore, when particularly unexpected or alarming errors occur, you can set your error handler to notify you via e-mail of the error, letting you know quickly of the error.  For example:

<CFIF GetProduct.recordcount IS 0>

Sorry, error XXXXX, product not found

<CFMAIL to="michael@teratech.com" from="michael@teratech.com" subject="Error XXXXX occurred">

Warning!  Error XXXXX occurred on your_page.cfm.  Page was called from #cgi.HTTP_REFERER# from remote address #cgi.REMOTE_ADDR#.

</CFMAIL>

<CFELSE>

… regular page operation here.

 

Use CFCATCH and CFTRY to prevent ColdFusion's built in error handling from exposing system data.  CFCATCH and CFTRY are somewhat tricky to use correctly and it is important to remember the basics of using them, such as:

1.        The CFCATCH and CFTRY must be in the same page, you can not put one in application.cfm or a header and the other in OnRequestEnd.cfm or a footer, they should both reside in each page.

2.        Errors in includes files will be caught. Errors in the application.cfm and OnRequestEnd.cfm will NOT be caught - these pages require their own separate error handling.

3.        Error messages may occur in the middle an HTML table and so may be not visible until you view the page source, keep an eye out for pages that display incorrectly, this may be an indication of error.

4.        Surround all code with CFCATCH and CFTRY - any errors that occur after the catch can not be caught!

5.        Also, CFCATCH error variables are different from the older CFERROR variables.

6.        If you get an error in your error handler you may not see any error message on it!

Here is some sample code to get you on your feet with good error handling:

 

<CFTRY>

           <CFINCLUDE TEMPLATE="header.cfm">

           your code here...

           <CFINCLUDE TEMPLATE="footer.cfm">

 

           <CFCATCH TYPE="Any">

           <CFINCLUDE TEMPLATE="ErrorHandler.cfm">

           </CFCATCH>

</CFTRY>

 

In the ErrorHandler.cfm put:

 

           Error occurred<br>

           <!--- Log error to file --->

Text Box: Where can I get more information on security?

Here are a list of web sites that cover security for ColdFusion and the Web in general: 
ColdFusion Specific
·	Allaire Tech Support
http://www.allaire.com/support
·	Allaire Security Zone
       http://www.allaire.com/security
·	TeraTech's ColdCuts:
http://www.teratech.com/coldcuts 
·	House of Fusion
http://www.houseoffusion.com/
·	CF-Talk Mailing List Archives
http://egroups.com/list/cf-talk
Net Security
·	L0pht
http://www.l0pht.com/
·	Rootshell
http://www.rootshell.com/
·	NT BugTraq
http://www.ntbugtraq.com/
·	Hacker News Network
http://www.hackernews.com/
·	Anti-Online
http://www.antionline.com/ 
Government Related
·	CSTS at LLNL.gov
http://ciac.llnl.gov/cstc/
·	CIAC
http://ciac.llnl.gov/ 
·	FedCIRC
http://www.fedcirc.gov/
·	CERT
http://www.cert.org/
           <cffile action="APPEND"

                   file="#ErrorLog#"

                   output="#now()# #CGI.CF_TEMPLATE_PATH# #CFCATCH.Message#">

 

           <CFMAIL TO="michael@teratech.com" FROM="michael@teratech.com"

              SUBJECT="Error on page #CGI.CF_TEMPLATE_PATH#">

              There was an error on #CGI.CF_TEMPLATE_PATH#.

              On  #now()#

  Type: #CFCATCH.Type#

              Message: #CFCATCH.Message#

              Details: #CFCATCH.Detail#

           </CFMAIL>

To Learn More

If you are interesting in learning more about ColdFusion CPCUG and TeraTech are holding a free ColdFusion User Conference - CFUN-2K on Saturday 7/29/2K and Sunday 7/30/2K at the Masur and Lipsett Auditoriums from 9am to 6pm. You can sign up for the conference at http://www.cfconf.org/ or call 301-424-3903.

You can download a free 30-day evaluation version of ColdFusion from Allaire or request a free eval CD-ROM from the Allaire website http://www.allaire.com/

 

Allaire Corporation

1 Alewife Center

Cambridge, MA 02140

 

Phone: 617.761.2000

Toll Free: 888.939.2545

Email: sales@allaire.com

Web: www.allaire.com

ColdFusion Resources

Allaire also maintain an extensive knowledge basis and tech support forums on their website.

CPCUG and TeraTech ColdFusion Conference - CFUN-2K

http://www.cfconf.org/

 TeraTech maintains a ColdFusion code cuttings called ColdCuts at http://www.teratech.com/ColdCuts/.

The Maryland ColdFusion User Group meets the second Tuesday of each month in Rockville, MD.  See http://www.cfug-md.org/ for details and directions.

The DC ColdFusion User Group meets the first Wednesday each month. See the DCCFUG page on http://www.figleaf.com/ for details and directions.

Bio

Michael Smith is president of TeraTech, a ten year-old Rockville, Maryland based consulting company that specializes in ColdFusion, Database and Visual Basic development.  David Schroeder is a ColdFusion developer for TeraTech. You can reach Michael or David at michael@teratech.com or 301-424-3903.


Home | Links | Articles | Past Meetings | Meeting Photos | Site Map
About MDCFUG | Join | Mailing List |Forums | Directions |Suggestions | Quotes | Newbie Tips
TOP

Copyright © 1997-2017, Maryland Cold Fusion User Group. All rights reserved.
< >