Security improvements in ColdFusion 10

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.

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).

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:

Application.cfm

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:

Note: Select encoding methods based on the context you plan to use the data.

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.

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:

The likethispage.cfm first check for authenticated user and like the page, as follows:

An attacker can easily perform a CSRF by creating an image tag, as follows:

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.

test.cfm

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.

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.

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:

test.cfm

createuser.cfm

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.

ClickJacking

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.

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.

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.

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:

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.

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

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.

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:

• Security improvements in ColdFusion (video)
• My blog
  
• Adobe ColdFusion Blog
  
• OWASP Cheat Sheets
• Adobe ColdFusion 10 documentation