Prerequisite knowledge
Basic knowledge of web application development with ColdFusion
User level: Intermediate
Required products
Adobe ColdFusion Enterprise Edition (2016 release) (Download trial)
Sample files
Security has always been important and core to web application development. Adobe ColdFusion has evolved to allow application developers protect against various security vulnerabilities and attacks. We have loaded Adobe ColdFusion 10 with security features. We put a lot of consideration on security in ColdFusion 10, including adding process improvements, a Security Hot-fix schedule, a built-in Hot-Fix Updater, Secure settings by default, and APIs to protect against security holes. In other words, ColdFusion 10 is a security-rich release.
In this article you will learn about various vulnerabilities that ColdFusion 10 takes care of, APIs to protect applications, and about creating a secure profile. After reading this article and applying some of the tips mentioned, you will be able to write more secure and safe applications, and protect your server better.

Using APIs and configurations for securing applications

In this section you will learn about configurations and APIs to protect against various vulnerabilities. Understanding an attack is very important in order to fix it or prevent it. I briefly touch on some of these attacks, for more details refer to resources section.
About sessions
Session-enabled stateless HTTP becomes stateful, and contains user related data. Whenever a new session starts, the server generates a random token called "session ID" and in most cases stores it on the client's browser as a cookie. Securing the session ID is very important, as it is much like the key to a vault. Lots of attacks happen due to weak or random session IDs, or by failing to secure the session ID on the client side.
In ColdFusion sessions, CFID and CFToken are session identifiers. Users control whether to keep a randomized value for CFToken or not. However, in a while you will see that it is strongly recommended that you should randomize CFToken . Hence, we have set the configuration for having randomized values for CFToken . Note that most of the APIs don't apply to J2EE session identifier ( JSESSIONID )
Now let's see some of the attacks that could possibly take advantage of the session ID. Later in this section, I give guidelines and remedies to these problems.
Session ID-related attacks
The following is a list of session id-related attacks that can occur.
Session Hijacking
In session hijacking, an attacker steals user's session ID and uses the web application in the victim's ID. In this scenario, the authentication mechanism becomes ineffective, even if the server generates the session ID after the authentication. Now each request using this session ID is all that your application requires. Here are some of the ways an attacker can hijack a session and how you can protect against it.
On an insecure network, an attacker can sniff the cookie consisting of session ID. For example, on an unencrypted wireless LAN.
Solution: Use secure connections and enable SSL for your application. (Enabling SSL is a topic covered in the Lockdown Guide for ColdFusion 9). Also, in ColdFusion Server administrator, specify the settings to secure session ID cookies. See details in the section below: ColdFusion 10 APIs - Application level.
Using the Cross-Site Scripting (XSS) exploit, an attacker can obtain access to a user's cookies.
Solution: Set the HTTPOnly flag on critical cookies so that they are not accessible using scripts. You can specify the HTTPonly attribute with the CFCOOKIE tag to make a cookie HTTPOnly . For example:
<cfcookie name="test" value"testcontent" httpponly=true>
See details in the section below ColdFusion 10 APIs - Application level settings.
Session Fixation
In session fixation, rather than stealing a user's session ID, the attacker may fix a session ID known to him or herself. In this type of attack, the attacker can do the following:
  • Create a new valid session with the target web application.
  • Force the victim to use this ID by using XSS or by sending him a link with the infected page where he will add script like the following:
When the victim accesses the application and authenticates himself, he and attacker both co-use the application with same session.
Solution: The most effective solution is to reset the session identifiers after a successful login. Also, set up your application so that it does not reuse tokens that the user supplies when starting a new session. With ColdFusion 10, we have added two very useful methods: SessionRotate , and SessionInvalidate. See more on these methods in the section below, ColdFusion 10 APIs.
Guidelines for protecting your sessions
The following section explains how to protect sessions with administrator settings and using ColdFusion 10 APIs.
Protecting sessions programmatically with settings
Use secure connections SSL.
Protect session cookies with HTTPOnly and Secure flags .
Set minimal session expiration time as sessions that never expire or have long expirations increase the vulnerable time window for an attacker.
Don't store large objects and critical data in session. If required, encrypt such data before placing it in session.
Reset session identifiers after successful authentication.
We have protected the ColdFusion Administrator console against Session Fixation by using the method SessionRotate , proper cookie security, and with minimal session durations.
Protecting sessions with ColdFusion 10 APIs
  • SessionInvalidate: This method clears all the data stored in session. Use this method whenever you need to have a user log out. The method syntax is simple: <cfset SessionInvalidate()>
Note: This method does not invalidate underlying J2EE sessions, when you have enabled J2EE sessions.
SessionRotate: After a user successfully logs in, reset the session to avoid session fixation issues. When you invoke SessionRotate ColdFusion performs the following process:
  1. Copies the current session's data.
  2. Invalidates the current session.
  3. Generates a new session.
  4. Copies the data from this invalidated session id to a newly-generated session with a new session ID.
The following is the syntax for using this method: <cfset SessionRotate()>.
  • SessionGetMetaData: This method returns session-related properties. The following is the syntax for using this method: <cfset sessionMetadata = SessionGetMetaData()>
  • Securing session cookies: In ColdFusion 10, you can configure the session cookie's properties using ColdFusion Administrator or using application.cfc. You can also configure HttpOnly, Secure, Expiry, and Domain.
  • Using the Administrator console to secure session cookies: In the Administrator, go to the Settings > Memory Variables page. There is a new section Session Cookie Settings. By Default, we have enabled HttpOnly with an expiration of 30 years (for maintaining backward compatibility). I strongly recommend that you set the expiration for Cookie Timeout to a much smaller value (Figure 1).
Figure 1. Configuring cookies from the Administrator console
Figure 1. Configuring cookies from the Administrator console
By enabling the "Disable updating ColdFusion internal cookies using ColdFusion tags/functions" option setting, your server will not allow attackers to manipulate CF-related cookies created with the CFCookie or CFHeader tags. This gives you more control over where you want to enable the manipulation of these cookies. A similar setting is available at the application level as well.
  • Application-level settings for securing session cookies:
You can insert the following code to set session cookies with more control in Application.cfc and Application.cfm. You can use the sessioncookie struct, in which you can specify the settings for CFID and CFTOKEN; meanwhile, you can use the Authcookie structure specifically for CFAuthorization cookie, which you might set when you use the cflogin tag.
See an example of using these application-level settings in the following Application.cfc file:
<cfcomponent> <cfset = "sessionCookies_test" > <cfset this.sessionManagement=true> <cfset this.setdomaincookies = true > <cfset this.sessioncookie.httponly=true> <!--- if cookie to be httponly ---> <cfset this.sessioncookie.timeout = "10" > <!--- session cookie age ---> <cfset = "true" > <!--- only https session cookie ---> <cfset this.sessioncookie.domain = "" > <!--- domain for which session cookies are valid ---> <cfset this.authcookie.timeout = createTimeSpan(0, 0, 0, 20) > authentication cookie age ---> <cfset this.sessioncookie.disableupdate = true > <!--- if session cookie can be modified by coldfusion tags ---> <cfset this.authcookie.disableupdate = true > <!--- if session cookie can be modified by coldfusion tags ---> </cfcomponent>
<cfset sesisonCookieProperties = {httponly='true', timeout=createTimeSpan(0, 0, 0, 10), secure='true',domain="",disableupdate=true}> <cfset authCookieProperties = {timeout=createTimeSpan(0, 0, 0, 10),disableupdate=true}> <cfapplication name="sessionCookies_test_appcfm" sessionmanagement="Yes" sessiontimeout="#createTimeSpan(0,0,30,0)#" sessioncookie=#sesisonCookieProperties# authcookie=#authCookieProperties#>
Cross-Site Scripting (XSS)
Cross-site Scripting attacks are a kind of injection problem, where an attacker uses malicious client-side scripts to inject into trusted web applications. Cross-Site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Such an attack can occur in any application where there is user input within the output the application generates, without validating or encoding it. This type of attack is possible in stored XSS, reflected XSS, DOM XSS, and so forth.
Solution: To protect against this type attack, validate user input and encode it before showing it as output or saving it on the server (Stored XSS).
The most common example of XSS is when an attacker steals cookies using JavaScript. An attacker uses the simple code below:
encodeForHTML(inputString, [strict]) encodeForHTMLAttribute(inputString, [strict]) encodeForCSS(inputString, [strict]) encodeForJavaScript(inputString, [strict]) encodeForURL(inputString, [strict]) encodeForXML(inputString, [strict]) decodeForHTML(inputString) decodeFromURL(inputString)
Note: Select encoding methods based on the context you plan to use the data.
<cfif isDefined ("form.submit")> <b>Output:<cfoutput >#encodeForHTML(form.userName)#</cfoutput></b> <cfelse> <cfset form.username=""/> </cfif> <cfform action="#cgi.SCRIPT_NAME#" method="post" > <cfinput name="userName" type="text" value="#form.userName#"> <cfinput name="submit" type="submit" value="Submit"> </cfform>
For example: encodeForHTML(inputString, [strict]).
This example displays the text entered in name field. If you enter a script function, say alert() and execute() .
Note: Many of the modern browsers have some basic protection against scripting; you might need to disable that protection for testing.
Observe that the script displays as text.
<cfif not isDefined ("form.submit")> <cfset form.width = 200 /> </cfif> <cfoutput> <table width="#encodeForHTMLAttribute(form.width)#" border="1" bgcolor="RED"> <tr><td>Enter the value in the below text field.</td></tr> </table> </cfoutput> <cfform action="#cgi.SCRIPT_NAME#" method="post" > <cfinput name="width" type="text" value="#form.width#"> <cfinput name="submit" type="submit" value="Submit"> </cfform>
These are some of the examples for encoding. See details in the OWASP XSS cheat sheet.
Cross Site Request Forgery (CSRF)
In Cross-Site Request Forgery (CSRF), also called one-click attack or session riding, the attacker forces the victim's browser to execute unwanted actions on a web application in which he/she is currently authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. Though CSRF has some pre-conditions that an attacker must set in place before he succeeds, it is an important attack to understand and protect against. The following section provides simple examples, however, real-life scenarios may be much more complicated. CSRF attack is possible with both POST and GET requests.
CSRF attacks using the GET request
Suppose a web application has a link which lets an authenticated user "like" a page, as follows:
<a href="likethispage.cfm?pageid=112">Like Me</a>
The likethispage.cfm first check for authenticated user and like the page, as follows:
<cfif IsUserLoggedIn() > <cfset user = GetAuthUser() > <cfset pageid = url.pageid> <!--- In real life web app sanatize this as well---> <!--- remaining logic to like the page by user---> </cfif>
An attacker can easily perform a CSRF by creating an image tag, as follows:
<img src="http://<mydomain>/pages/likethispage.cfm?pageid=112" height="1px" width="1px" />
The attacker can then put this image to any web page and trick the user to just visit the page. If a logged in user just visited the page, the browser will automatically like the page, without the user knowing.
CSRF using a POST request
Now I will show a web application in which only site administrator can create a user. The administrator has to first log in (get authenticated) to the web application and create a user with a simple web form. I am not including authentication code here to keep the example simple.
<cfform method="post" action="http://<sitedomain>/createuser.cfm"> Username : <cfinput name="username" type="text" > <br/> Password : <cfinput name="password" type="password" ><br/> Verify Password<cfinput name="verifyPassord" type="password" ><br/> <cfinput name="Submit" type="submit" value="Create User"> </cfform> <br/>
An attacker can host a form in a different domain with the action attribute target of http://<sitedomain>/createuser.cfm, using all hidden fields and with pre-filled values; eventually using JavaScript to submit the form, as follows.
<form method="post" name="hackForm" id="hackForm" action="http://<sitedomain>/createuser.cfm"> <input type="hidden" name="username" value="eviluser"> <input type="hidden" name="password" value="evilpass"> <input type="hidden" name="verifyPassord" value="evilpass"> </form>
The attacker can host this form in any domain, such as http://<evildomain>/hackme.html, or generate a shortened URL (using any URL shortening service) so that the URL doesn't look suspicious. The attacker then tricks the authenticated administrator into clicking the ill-intended URL. He can do so by sending this link in an e-mail, or posting it on a forum that the administrator visits. If the administrator is logged into the application, and clicks on the URL, the hacker's application will create a new user without the administrator's knowledge. Because the administrator is logged into the application prior to clicking the ill-intended link, the application is unable to distinguish it as an unwanted action.
Next, you will learn how you can protect your applications against CSRF attacks.
Protecting against CSRF attacks
In ColdFusion 10, we added two new functions to protect your web application against a CSRF attack.
CSRFGenerateToken([key],[forcenew]) and CSRFVerifyToken(token,[key])
We implemented these functions using the Synchronizer Token Pattern approach to prevent CSRF attacks. You can read in detail about this in the OWSAP CSRF Prevention Cheat Sheet. This technique generates a token and saves it in the user session, while copying is the token in a form post input or as URL parameter. When your application submits a request, using this technique, your application should also validate this token against the one stored in session. Since these methods typically store tokens in session, make you enable session management in your Application.cfc or Application.cfm.
Key parameter: You can use this parameter so that you have different tokens for different sections of the application.
  • Forcenew parameter : If you set this parameter to true, it will generate a new token on each invocation.
Depending on application's design, I strongly recommend you use these values. Now let us write the same example with CSRF protection:
<cfset csrftoken= CSRFGenerateToken()/> <cfform method="post" action="http://<sitedomain>/createuser.cfm"> <cfinput name="csrftoken" type="hidden" value="#csrfToken#"> Username : <cfinput name="username" type="text" > <br/> Password : <cfinput name="password" type="password" ><br/> Verify Password<cfinput name="verifyPassord" type="password" ><br/> <cfinput name="Submit" type="submit" value="Create User"> </cfform>
<cfif (not isdefined("form.csrfToken")) or (not CSRFVerifyToken(form.csrfToken)) > <p> I am smart, no hacking zone :P </P> <cfabort> <cfelse> <!---- Application logic ---> </cfif>
By invoking CSRFGenerateToken , ColdFusion generates a random token and puts that token into the user session; you as the application developer must put this token into the form as hidden field or any actions that you want to protect from CSRF. The CSRFVerifyToken(token) code passes the token as a parameter and verifies it with the token stored in the session.
Now even if the site administrator clicks on the link http://<evildomain>/hackme.html, the form won't be able to create a user because that form does not have a CSRF token. To make CSRF work, the hacker needs to be able to steal the CSRF token and put that into the form, however, that is next to impossible if you have validated the token for a particular session.
In Clickjacking (UI redressing) a web application user, a hacker tricks a user into clicking something different to what the user perceives he/she is clicking; thus, the user potentially could reveal confidential information or the user could take control of the user's computer when the user clicks links on seemingly innocuous web pages. In Clickjacking, an attacker uses multiple transparent or opaque layers to trick a user into clicking a button or link on another page when the user intends to click a link or button on the top-level page. Thus, the attacker "hijacks" clicks meant for a different page and routes the user to other another page most likely owned by another application, domain, or both.
There are various methods to protection against clickjacking. Some client-side protections include using tools like NoScript, Ghostery, GuardedID, and so forth. On the server-side, you can use frame-busting code. Most new web browsers have a new protection called an X-Frame-Options header. You can set this header with "SAMEORIGIN" or "DENY" values, where the browser permits frames only in the same domain.
ColdFusion administrator protect against clickjacking using X-Frame-Options. You can also extend this option further to protect your applications, as follows:
  1. Open the Web.xml file located at <Server-doc-root>/WEB-INF.
  2. Add URL filter Mapping for your application with one of the two filters already specified: CFClickJackFilterSameOrigin or CFClickJackFilterDeny.
Now let's say that you have an application testClick, which you want to protect against clickjacking by denying a frame for application. To do so, add the following in the web.xml file.
<filter-mapping> <filter-name>CFClickJackFilterDeny</filter-name> <url-pattern>/testClick/*</url-pattern> </filter-mapping>
Improved CFLogin tag
With ColdFusion 10, we have improved and made the CFlogin tag more secure, especially in the authorization process that occurs when you use the cflogin tag with loginstorage= "cookie".
The Authorization cookie set is more secure in the following ways:
  • The cookie has a short time to live.
  • The cookie expires by default on browser close; you can configure the expiration by using cookie settings discussed in previous sections.
  • The cookie is specified by default to be HttpOnly for the ColdFusion administrator console. For other applications, there is a provision to configure.
There are however some behavioral changes, as follows:
  • Now you can have only one active session open for one user for a given application that uses the cflogin tag.
    • For example, you can now access the Administrator console one user at a time with a given set of UserIDs and passwords.
  • In a clustered environment, if you have not enabled sticky sessions, the cflogin will not persist. On each request, there is a need for the user to log in again. To fix this issue, do the following:
    • Enable distributed caching for authcache in <cf-home>/lib/auth-ehcache.xml.
    • Enable cache replication for the nodes of a cluster.
    • Note: The cacheManagerPeerListenerFactory port should be unique for each node in cluster.
    • To enable long lived logins or remember me type of functionality, do the following:
      • Increase authcookie.timeout to a large enough number in Application.cfc and Application.cfm.
      • Make the cache persistent by updating the configuration in auth-ehcache.xml.
Note: Elements in this cache have an idle timeout same as session timeout specified at Application level or at server level.
I have provided a sample auth-ehcache.xml with RMI replication enabled in the ZIP file available in the Requirements section at the beginning of this article.
User management and sandbox
ColdFusion 8 made creating and managing users very easy. Before ColdFusion 10, it was possible for you to allow access to the sandbox for a new user, who could then use it for Remote debugging purposes using RDS (Remote Debugging Service). At the time of development, users could access particular files/directories and data sources that the administrator specified. If a user were given access to a sandbox with "All Files" access enabled, the user could misuse that power. In ColdFusion 10, you can give a user access to particular files/directories and data sources, by granting these permissions only when you have enabled RDS. This enables a more granular control on services that a user can access.
I will not go in detail about creating a user; I assume you all have seen or done that before. Instead, I will point out the differences in creating a user.
Figure 2. User Management
Figure 2. User Management
Notice that there is no section for adding access to User Sandboxes. Instead there are two new sections :
Sandboxes: Data Source Permissions
Sandboxes: Add / Edit Secured Files and Directories
You can grant appropriate access for data sources and files/directories.
For Sandbox Creation, we have changed the default settings to make them more secure.
Response-splitting attack (CRLF)
CRLF refers to Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n). A CRLF attack occurs when a an attacker manages to submit a CRLF into an application. When an attacker does this, he/she can add or modify headers or even complete a response packet.
In ColdFusion 10 we added in-built protection against CRLF attacks for tags that create a header, for example, in cfheader , cfcontent , cfmail , cfmailpart , and cfmailparam .
IP-based access for the Administrator Console
We added the Whitelist filter for Administrator access. In the ColdFusion administrator, go to Security > Allowed IP Addresses > Allowed IP Addresses for ColdFusion Administrator access. If you specify no IP, all IPs can access the administrator.
Figure 3. Specifying allowed IP addresss for Administrator access
Figure 3. Specifying allowed IP addresss for Administrator access
Audit logging
We added audit logging for critical administrative activities to help you identify system misuse. Audit logging logs a lot of activities such as when a user logs in or logs out, logs changes in security-related specifications, and logs a lot of other configurations. You can add these specifications in the <SERVER_Home>/logs/audit.log file.
For example, you can change the log as follows:
"Information","catalina-exec-4","<date>","<timestamp>","CFADMIN","User admin logged in." "Information","catalina-exec-24","<date>","<timestamp>","User admin disabled RDS security" "Information","catalina-exec-4","<date>","<timestamp>","CFADMIN","User admin logged out"
Setting the Post Parameters Limit option to protect against DoS using Hash Collision
You can use the Post Parameters Limit option in the administrator to prevent against DoS (Denial of Service) attacks, which attempt to take advantage of Hash Collisions. The default value for this setting is 100. Modify this setting in the administrator Settings section.
Figure 4. Settings -> Post Parameter Limit option
Figure 4. Settings -> Post Parameter Limit option

Creating a secure profile

Secure profile is a new option available when you install ColdFusion 10. We recommend that you install this option for production or public-facing servers. This option enforces a lot of security-related configurations, and requires the administrator to enable fewer options to secure the server. During installation, if the administrator chooses to install the secure profile option, the following settings are in effect:
  • ColdFusion enables separate username and password for Administrator and RDS.
  • ColdFusion disables the RDS service.
  • ColdFusion asks you for a list of IP addresses that should have access to Administrator.
  • ColdFusion requires you to create a strong and complex password for the root admin user.
  • ColdFusion disables Directory Browsing in the server
  • ColdFusion provides custom and least information error templates
  • ColdFusion disables all debugging
  • For a new data source default allowed SQL are now select, insert, update, delete
  • Below is a list of other settings on server level that ColdFusion sets.
Secure Profile Settings 1
Administrator Settings
Default Admin
Secure Profile
Changes to the setting
Use UUID for cftoken
Server Settings > Settings
Disable access to internal
ColdFusion Java components
Server Settings > Settings
Enable Global Script
Server Settings > Settings
Maximum size of post data
Server Settings > Settings
Missing Template Handler
Server Settings > Settings
no value
Custom missing error template
Retained if specified
Site-wide Error Handler
Server Settings > Settings
no value
Custom site-wide error template
Retained if specified
Request Queue Timeout Page
Server Settings > Request
no value
Custom error template
Retained if specified
Cookie Timeout
Server Settings > Memory
15767000 minute
1440 minute
Disabling updating of ColdFusion internal cookies using ColdFusion tags/functions
Server Settings > Memory
Enabled WebSocket Server
Server Settings > WebSocket
Start Flash Policy Server
Server Settings > WebSocket
Allowed SQL (all settings)
Data & Services > Data Sources ><database> > Advanced Settings
Create, Drop, Alter, Grant,Revoke, Stored Procedures are disabled
Retained if specified
Enable Robust Exception Information
Debugging & Logging > Debug Output Settings
Debugging & Logging > Debug Output Settings
Select the type of
Administrator authentication
Security > Administrator
Use a single password only
Separate user name and password authentication (allows multiple users)
Enable RDS Service
Security > RDS
Configurable at install time
Select the type of RDS
Security > RDS
Use a single password only
Separate user name and password authentication (allows multiple users)
Allowed IP addresses for ColdFusion Administrator access
Security > Allowed IP Addresses
Not available at install time
Available at install time
In summary, ColdFusion 10 has many security features. You can take advantage of all these features and make your applications much more secure in less time.

Where to go from here

Now you have an understanding of how to secure your applications and about the new security features in ColdFusion 10. Securing applications is much easier with ColdFusion 10 than in previous versions. I have written blog entries explaining lot of potential attacks and how to protect against them. See the resources below for more information: