Security enhancements in ColdFusion 10 let you reduce XSS and CSRF attack vulnerability. The enhancements also help you manage ColdFusion sessions effectively. The release also includes fixes that reduce other vulnerabilities.

XSS attack

Cross-site scripting (XSS) attacks bypass client-side security mechanisms imposed by web browsers. These methods use Open Web Application Security Project's (OWASP) Enterprise Security API for encoding. An attacker injects malicious scripts into a web page to access information stored in the browser.

  • Only the following characters are allowed as values for the attribute name in the tag cform: alphanumeric characters, _ (underscore), - (hyphen), : (colon), and . (dot). It prevents stored XSS for the scriptsrc field.
  • The following new encoding methods are added to reduce XSS attack vulnerability: EncodeForHTMLEncodeForHTMLAttributeEncodeForJavaScriptEncodeForCSS, and EncodeForURL. Encode the user inputs depending on the contexts. To decode the input string, added a method: Canonicalize.

CSRF attack

Cross-Site Request Forgery (CSRF) forces users to execute unwanted actions on a web application for which they are authenticated. For example, sending a URL using an email or chat to a privileged user. Clicking the URL link forces the user to do an action of the attacker's choice.

  • Following methods can be used to reduce CSRF vulnerability:
    • CSRFGenerateToken: Returns a random token and stores it in the session.
    • CSRFVerifyToken: Validates the given token and the key against the same stored in the session.*Example: CSRFGenerateToken*The following example lets you enter value and submit. The page generates a token and calls another ColdFusion page.

      <cfset csrfToken=CSRFGenerateToken() />
      <cfform method="post" action="sayHello.cfm">
      <cfinput name="userName" type="text" >
      <cfinput name="token" value="#csrfToken#" type="hidden" >
      <cfinput name="submit" value="Say Hello!!" type="submit" >

      The following page, sayHello.cfm, validates the token generated and displays the output of CSRFverifyToken(token).

      <cfset validate = CSRFverifyToken(token)>
      <cfoutput >#validate#</cfoutput>

Note: Enable SessionManagement for protection against CSRF. Disabling session variables in the administrator console disables CSRF protection.

Session improvements

You can manage ColdFusion session cookies effectively.

CF Session cookies (CFID, CFTOKEN, CFAuthorization_<app-name>)

The new features to manage session cookies are:

  • The following properties of ColdFusion session cookies can be configured at server level or application level:
    • httponly: true by default
    • secure: false by default
    • domain
    • timeout: 30 years by default
      You can set the session cookies at the application level by specifying the settings as a struct in the Application.cfmas shown in the following example:

      <cfset cookieast = {timeout=createTimeSpan(0, 0, 00, 10)}>
      <cfapplication name="sessionCookies_appcfm_allSetting" sessionmanagement="Yes" sessiontimeout="#createTimeSpan(0,0,03,0)#" scriptprotect="all" sessioncookie=#cookiest# authcookie=#cookieast#>

Note: The application level setting takes precedence over the server level setting.

Use the following new admin APIs to set session cookies at the server level by providing the parameters getRuntimeProperty and setRuntimeProperty. These methods are available in the CFIDE\adminapi\runtime.cfc file.The following example explains how to get the cookie parameters using the getRuntimeProperty() method. Set the cookie parameters in the similar way using the setRuntimeProperty() method.


  • The session cookies can be set at the application level by specifying the following in the Application.cfc:
    • this.sessioncookie.httponly="true"
    • this.sessioncookie.domain="value"
    • this.sessioncookie.timeout="value" (days)
    • this.authcookie.timeout= "value"(-1 by default. Cookie is valid until the browser is open.)

      Note: You can define the SetDomainCookies property and set session cookies for domain at application and server level. In this case, the precedence is as follows: application settings, server settings, and the SetDomianCookies property.

Note: The system property, coldfusion.sessioncookie.httponly=true, that was added in ColdFusion 9.01 is not required in this release and therefore has been removed.

Note: Using CFCookie and CFHeader tags to manipulate ColdFusion cookie and authorization cookie can be controlled in application or server level configuration. Add the following in application.cfc or application.cfm: sessioncookie.disableupdate=true and authcookie.disableupdate=true. You can also use the following methods in the CFIDE\adminapi\runtime.cfc: GetRuntimeProperty("CFInternalCookieDisableUpdate") and {{SetRuntimeProperty("CFInternalCookieDisableUpdate", "true/false")}}To set the tags in the ColdFusion administrator, go Server Settings > Memory Variables > Session Cookies Settings. Select or deselect "Disable Updating ColdFusion internal cookies using ColdFusion Tags\Function ."

  • ColdFusion 10 and ColdFusion 11: If you enable SetDomainCookies in a ColdFusion application, then a domain hash appends to the cookie values of both CFID and CFTOKEN for better session security. ColdFusion 10 and ColdFusion 11 HF 14 has this behavior.
  • ColdFusion 2016: There is a new JVM argument added, "coldfusion.cookie.prefixdomainhash". Setting this argument to false disables adding the domain hash prefix to CFID and CFTOKEN, even when SetDomainCookies is set to true. The new argument allows multiple versions of ColdFusion to share the session.
  • The <cflogin> tag stores the password in cache. For longer authenticated sessions, you can enable diskPeristent by modifying authcache located in the cfhome/lib/auth-ehcache.xml file. The directory used for persistence should be secured.

CRLF attack

Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n) (CRLF) attacks also referred as HTTP Response Splitting. Here, an attacker injects CRLF to an http stream. It is commonly done by modifying an HTTP parameter or URL. In this way, CRLF can be injected into an application and can be included in response. The CRLF interpreted by proxies and caches create serious security issues.

  • Protection is added against CRLF attacks for the tags which create a header, for example, cfheader, cfcontent, cfmail, cfmailpart, and cfmailparam.

Information disclosure

This feature improves security-related issues on information disclosure.

  • Passwords for all services are encrypted in this version. Change password seed only when the server is running without any load. Otherwise, you face unexpected behavior of the server.

New HMAC method

Hash-based Message Authentication Code (HMAC) is used to verify the data integrity and authenticity of a message transmitted. It involves a cryptographic hash function in combination with a secret key. The cryptographic hash function can be Message Digest 5 (MD5), and Secure Hash Algorithm (SHA), and so on.

cfcookie support in CFScript

Cookies can be set as a struct in CFScript. You can set the following parameters:

  • expires
  • value
  • name
  • secure
  • httponly
  • domain
  • path
  • preservecase
  • encodevalue
    Example 1

cookie.mytest = {value="Adobe",expires="10",secure="true",domain="",path="/coldfusion"};

Example 2

cookie_example = structNew();
cookie_example.value = "example";
cookie_example.expires = "10"; = "true";
cookie.mycookie = cookie_example;

Miscellaneous Changes

  • The httponly cookies support is available on Tomcat supporting J2EE 1.6.
  • A new parameter, numIteration, is added to the hash() method.This optional parameter specifies the number of times the hash is iterated. The updated hash()method is as follows:

    hash(Object message, String algorithm, String encoding, int no-of-iterations)

    The first argument can be an object of String or Byte type.


    <cfif IsDefined("Form.UserID")>
    <!--- query the data base. --->
    <cfquery name = "CheckPerson" datasource = "cfdocexamples">
    SELECT PasswordHash FROM SecureData WHERE UserID = <cfqueryparam value = "#Form.userID#" cfsqltype = 'CF_SQL_VARCHAR'>
    <!--- Compare query PasswordHash field and the hashed form password and display the results. --->
    <cfif Hash(Form.password, "SHA","",4) is not checkperson.passwordHash> User ID #Form.userID# or password is not valid. Try again.
    <cfelse> Password is valid for User ID #Form.userID#.
    <!--- Form for entering ID and password. --->
    <form action="#CGI.SCRIPT_NAME#" method="post">
    <b>User ID: </b> <input type = "text" name="UserID" ><br>
    <b>Password: </b> <input type = "text" name="password" ><br><br>
    <input type = "Submit" value = "Encrypt my String"> </form>

  • Strengthened <cflogin>and authorization cookies. In a clustered environment, enable sticky session. If sticky session is not enabled, do the following:

    Note: Different ways of adding distributed cache can be found at the Ehcache website.

    • Configure authentication cache for the clustered environment. Do the following for each instance in the cluster:
    1. Open CF_instance/lib/auth-ehcache.xml.
    2. Search for the string, Mandatory Default Cache configurationand add the following entry:

      properties="peerDiscovery=automatic, multicastGroupAddress=,
      multicastGroupPort=4446, timeToLive=32"/>
      <cacheManagerPeerListenerFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory"
      properties="port=40002, socketTimeoutMillis=3000"/>
      <!-- distributed caching settings part 1 ends -->

    3. In the above entry, update the cacheManagerPeerListenerFactory properties port. It must be unique for each instance.
    4. Search for the string, <cache name="authcache".
    5. Add the following entry after clearOnFlush="true">.

      <cacheEventListenerFactory class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" properties="replicateAsynchronously=false, replicatePuts=true, replicatePutsViaCopy=false, replicateUpdates=true, replicateUpdatesViaCopy=true, replicateRemovals=true" propertySeparator=","/>

Note: ColdFusion administrator does not support cluster setup.

Note: For Remember Me type of functionalities or for keeping authentication cache alive for a long time, change the authentication cache settings. For example, increase time outs, enable persistent cache, and so on.

Note: Use new cookie configuration for more secured authentication. Depending on the requirement, do the configuration at the server lever or application level.

  • You are logged out from one of the ColdFusion administrators, if:
    • From the same host, you log in to the ColdFusion (10) Administrator and the ColdFusion Administrator of an older version.
  • For a user with RDS access, in the ColdFusion Administrator, you can set the data source and secured file path permissions.
  • The default values for the new sandbox are changed to make it more secure.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy