ColdFusion sessions vs J2EE sessions

6
votes

Are there any benefits to ColdFusion sessions vs J2EE sessions?

The ColdFusion session documentation mentions the benefits of J2EE sessions, but not any advantages of ColdFusion sessions. J2EE sessions have been available since ColdFusion MX (released in 2002), but there are still a lot of people using standard ColdFusion sessions. Are there any disadvantages of J2EE sessions that aren't present with ColdFusion sessions?

J2EE session management provides the following advantages over ColdFusion session management:

  • J2EE session management uses a session-specific session identifier, jsessionid, which is created afresh at the start of each session.
  • You can share session variables between ColdFusion pages and JSP pages or Java servlets that you call from the ColdFusion pages.
  • The Session scope is serializable (convertible into a sequence of bytes that can later be fully restored into the original object). With ColdFusion session management, the Session scope is not serializable. Only serializable scopes can be shared across servers.

Therefore, consider using J2EE session management in any of the following cases:

  • You want to maximize session security, particularly if you also use client variables
  • You want to share session variables between ColdFusion pages and JSP pages or servlets in a single application.
  • You want to be able to manually terminate a session while maintaining the client identification cookie for use by the Client scope.
  • You want to support clustered sessions; for example, to support session failover among servers.
4
sessionjakarta-eecoldfusion
From memory, CF native sessions don't use Session cookies, so can last across browser/machine restarts, whereas all default J2EE servers use session cookies,so your session can only last as long as your browser is open. I've not checked this in a long time, but that may be of use - barnyr
Yeah, that is still the case, good point. Put it in an answer and I'll upvote it, although I think that would be a negative point in a pentest. - nosilleg
possible duplicate of Disadvantages of J2EE session management in ColdFusion - Sergey Galashyn

4 Answers

3
votes

There are no serious disadvantages to using Java EE session cookies, and there are some advantages to using them, as indicated above in your question.

The one disadvantage to Java EE tokens is that the cookies cannot be easily modified programmatically. CF Tokens can. You can modify CF Tokens to be session only. You can also modify them to be SSL-only and httpOnly.

You can make Java EE tokens SSL-only and httpOnly as well, but it involves JVM arguments.

In CF9, Adobe also improved the randomness of CF Tokens to be more on par with Java EE tokens.

I really don't think it matters which one you use (assuming you're on CF9 or higher). But Java EE Tokens are the closest to working securely out-of-the-box. But if you want to go beyond just setting the cookies to "session-only" and have them be SSL-only and httpOnly, you'll need to dig into the JVM settings. You cannot do that in your App.cfc.

1
votes

CF native sessions don't use Session cookies, so can last across browser/machine restarts, whereas all Java EE servers by default use session cookies,so your session can only last as long as your browser is open.

I can't find where this behaviour is specified in the Servlet JSR, but in Servlet Spec 3.0 (i.e. not JRun) , you can set an expiry date for your Java EE session cookie in order to mimic the CF native session behaviour.

As nosilleg mentions, this is could be a bonus, but also could be seen as a security problem, depending on the security requirements of the app your're working on.

1
votes

One of the main disadvantages of J2EE session variables in ColdFusion is that changes such as making them "secure" cookies takes place instance wide.

This means that every site that is running on that instance must run under https, including ColdFusion administrator itself. For servers that host multiple sites that require sessions, this will generally be problematic. Additionally, if you're running the ColdFusion Administrator from the built in web server, there's a bit of a process to get that working under ssl.

If you need the documented advantages of J2EE cookies, and need the cookie to be secure then all sites that requires sessions must be on https.

If you don't need any of the documented advantages of J2EE cookies, and you're running CF9 or later, then you're better off going with ColdFusion cookies.

Note that Railo still has the same issue but with more flexibility since the cfapplication tag has a sessiontype attribute where you can choose between j2ee or cf session cookies on a per site basis.

0
votes

I had one tiny problem where I completely lost session variables between requests. I was using a cfhttp post with J2EE sessions. Imagine this scenario: 1. call.cfm in wwwRoot/test folder makes a call to an index page also in the same folder. 2. index.cfm sends the request to wwwRoot/test/controller/login.cfm. 3. login.cfm sets some session variables and sends the user to wwwRoot/test/index.cfm 4. index.cfm does not see the session variables created.

All the send requests are done via cflocation with addtoken="yes".

Turn off the J2EE session variables, and viola! It works just like the way it should.

cflocation and session variables