Session Tokens in ColdFusion - Security Series #6.1 part 2

So let's talk about these j2ee session tokens that I teased about in my last post.

You may recall that when we look at a CFToken it could look like:

MYAPP_103_13624879 (default version)

or

MYAPP_106_cd72ce3e98123588-75FEC96D-9137-2EF1-3880EA6C56CD1F4E (UUID version)

We also kind of decided in our last post that the UUID version of our session token was pretty secure. It would take like a bazillion years for a hacker to guess that CFTOKEN, why should we even bother looking at anything else?

That is such a good question, I am going to make it an H3 heading

Why should we even bother looking at anything else?

There are several reasons to use J2EE session tokens instead of ColdFusion session tokens. Some of them are for security, some are just for convenience.

For convenience:

  • They are serializable for sharing across servers/within clusters (CF Sessions are not serializable)
  • They can be shared with JSP pages and Java Servlets
  • You get to say "J2EE" and act like you know what you are talking about

For Security:

  • The Session can be programatiically invalidated

                <cfset getPageContext().getSession().invalidate()>
                
  • The session cookie is automatically deleted when the user closes their browser
  • You get all this PLUS you still get a 36 character session token

So now, to compare all three side-by-side (cause it's fun):

    
MYAPP_103_13624879 (default version)

MYAPP_106_cd72ce3e98123588-75FEC96D-9137-2EF1-3880EA6C56CD1F4E (UUID version)

f030a333d2a037f5381f3483b3b476d12244 (J2EE Version)


Now looking at this, you may say to yourself... "WFT?!". The UUID sessionid is WAAAAAY longer than the J2EE session token. Why would I use the J2EE token (Notice how often I get to say J2EE, pretty awesome, huh?).

You're right, the UUID token is WAAAAY longer. But remember, the "MYAPP_106_" part of it can be ignored, since we can figure that part out pretty easily just by going to get a session of our own. However, our CFToken has one SERIOUS disadvantage. If you are using ColdFusion session management (Standard or UUID), the session does not, I repeat DOES NOT, end when the user closes the browser.

Hypothetical time (I love these).

Consuela Maria Villarreal is sitting at her computer in the library looking for a date at http://coldfusiondating.com, which uses ColdFusion session management. When she is done, she logs off like a n00b (Which means she closes her browser).

Now along comes her stalker ex-beau who is up to no good and has a chip on his shoulder and eats pancakes for dinner. A real rebel. He sits down at the computer she was using 17 minutes after she closed the browser. He opens the browser, goes to http://coldfusiondating.com (just like you tried to do 15 seconds ago). What do you think he gets? That's right! He gets her profile. He is logged in as her and begins emailing her date for Tuesday night telling him to meet her at TacoHut instead of The Old Country Buffet (The Villain!).

You see, ColdFusion session management uses regular cookies for storing the session token, and since the server does not know that the user is going to close the browser, it cannot delete the cookies when the use does that. In fact, the server has NO WAY of knowing if the user closes the browser, at all, EVER, regardless of what kind of session management you are using! So once someone else launches the same browser (on the same machine in the same profile) the session cookie is transmitted to the page again (if the page is visited) and the server assumes that the session is legit.

So why don't J2EE sessions have this problem? Well, J2EE sessions use non-persistent/in-memory cookies for persisting the session in the bowser. If the browser is closed, those cookies are lost and the session cannot be reestablished (unless the cookie can be reconstructed).

So back to our hypothetical, Consuela's http://coldfusiondating.com account would not have been compromised, because once she closed the browser, here session tokens would have been lost.

So for what it is worth, I say, J2EE session management is the way to go. For those of you in clustered environments, it is the only way to go.

There is so much more to cover on this topic, please ask questions if you have them. I will continue posting about Session Management, but if there is something specific you want to read more about or have me research, let me know. All I ask is that it be security related.

Comments
Laura Norris's Gravatar so i set my server up for J2EE sessions, but it is using both the CF and J2EE session management. How do i get it to just use the J2EE session management?
# Posted By Laura Norris | 6/25/08 11:07 AM
Jason Dean's Gravatar @Laura - I suspect what you mean is that the CFID and CFTOKEN are still showing up in the URLString in your session. This is expected. I believe they are only there for backward compat. If the J2EE session id is showing up, then you are good to go, you can pretend like the others are not there.
# Posted By Jason Dean | 6/25/08 11:30 AM
Rich Rein's Gravatar You can ignore them - but theoretically, they should not be there anymore. Please be sure to verify that both the clientmanagement and setclientcookies options are explicitly set to no for your application.
# Posted By Rich Rein | 7/24/08 3:40 PM
Jason Dean's Gravatar @Rich, actually they are still there, regardless of what is set in your application.cfm/cfc. I believe this is by design. It is described here under the "Changes in MX" section:

http://kb.adobe.com/selfservice/viewContent.do?ext...
# Posted By Jason Dean | 7/24/08 9:50 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner