Session Tokens in ColdFusion - Security Series #6.1 part 1

Just like everything else in ColdFusion there are multiple ways to handle session tokens. Technically there is no "right way", however, some ways are better than others. At least, in my humble opinion.

So, as I discussed in my previous post session tokens are used to identify a client to the web server so that the server can relate the correct session information for that client.

Well, if our users' session tokens can be guessed or otherwise compromised, we could have malicious users impersonating our legitimate users. Here is how that can happen:

  1. Our legitimate user logs into the web application and is assigned a token. They spend some time on the site, look around, update their credit card information, and whatever else.
  2. Meanwhile, our legitimate user is using the site, a hacker has somehow obtained that users session token. (We will get into how that can happen another day)
  3. The hacker goes to our web application and receives a new session token.
  4. Using a Firefox extension like Add N Edit Cookies or Edit Cookies our hackers opens the cookie that our application created and pastes our legitimate users session token into it.
  5. The hacker hits refresh, the browser passes the new token to the server, and the server now thinks the hacker is the legitimate user.
  6. Now the hacker can use the web application as if he were the legit user, even if the legit user has logged off. As long as the session was taken over before it had a chance to expire. And since a session cannot be forced to expire, the session will persist up to the length of time you have set in your sessiontimeout settings on the server or in your Application.cfc. This can give your hacker a large window for intrusion.

This is called session hi-jacking.

So how can we prevent session hijacking?

One method is the use of more secure session tokens. So that they cannot be guessed and to narrow the window of opportunity for a hijack attempt.

One of the first things, and easiest things, you can do to secure your session tokens is to lower the timeout value for your users' sessions in your Application.cfc. In the Application.cfc psuedo contructor you can create (or modify if it already exists) this line.


<cfset this.sessiontimeout = CreateTimeSpan(0,0,10,0) />

This line tells the server to expire sessions after 10 minutes of inactivity. You should set the timeout value to a length of time appropriate to the security level required for your application.

For highly secure apps, like online banking, you would want it low, like 5 minutes. For less secure sites, like simple social networking sites that do not have personal data, maybe stick with the 20 minute standard.

You should try to choose a length that will not inconvenience your users, yet still make their sessions more secure. A 5 minute timeout for a Content Management System is highly unreasonable, since many times a user might spend 20 minutes or more entering data into a single form. If it timed out while they were doing that, they would get angry.

The second thing we can do, is make our session tokens less more difficult to guess. By "guess" I mean less more difficult to find a valid token using a program like Burp Sequencer.

The default session tokens used by ColdFusion actually suck pretty bad. But first, let's talk about the different types of session management available in ColdFusion.

There are two types of session management available in ColdFusion. There are, ColdFusion Session Management and J2EE Session Management. They each have their pros and cons.

The default configuration of ColdFusion Session Management is the one that sucks. It uses a CFID and an CFTOKEN combined with the application name to create the session id.

So a standard session id in this set up would look like: MYAPP_103_13624879

Now you might say to yourself. "Huh, that seems pretty secure. It has letters and numbers, it's pretty long. It looks random enough:..."

Well, as it turns out, none of that is true. Yes it does have letters and numbers, but the letters are not really part of the security. In fact, everyone that visits this application will get those same letters because that is the name of the application that was assigned in the Application.cfc:


<cfset this.name = "myApp" />

So, we know that the first part is not secure. What about those three digits in the middle (Which is the CFID btw), are they randomly generated?

Nope.

They increment by one with each new session and max out at 4 digits, so the next person that visits and gets a new session will get CFID 104. So we already know the first half of the next persons sessionid. Huh, this does not bode well for the next person.

So what about that last group of number (the CFToken)? Surely that must be secure, look how long it is.

Well, the last set of numbers are (psuedo) randomly generated, that part is true. But secure... not really. The first problem is... they are only numbers! No letters, no dashes or other special characters, just numbers.

Now, since they are just numbers, it makes it real easy to do the math to determine how many possible CFToken values there could be. The CFToken is 8 charatcers long. So the math would be (10^8) or roughly one hundred million (100,000,000) possible values.

Wow, 100,000,000!!! That's a lot. Where are we ever going to find a computer that could try 100,000,000 session tokens in the 20 minutes it takes for a session to timeout?

Well, aside of the fact that just about any consumer PC could handle that kind of task, a few misconceptions can be easily reached when thinking about this.

  1. The hacker does not need to try all one hundred million to hit the right one. In fact after guessing half he's already had a 50% shot at getting one.
  2. The hacker is not limited to only the 20 minute period between the last thing that the end user does on the site to when the session times out. The hacker can be working on the hijack the entire time the user in on the site. That could be hours, or even days depending on the session timeout and any AJAX style keep-alive features like gmail has.
  3. The hacker is able to try again with the next user, if the last one fails.
  4. So how can we make our tokens less easily "guessed"

    Well, ColdFusion Administrator has a great feature under SETTINGS called "Use UUID for cftoken"

    What this feature does is it creates a UUID string of charatcers for the CFToken instead of those 8 stupid little digits.

    A UUID is a 35 character alphanumeric string with an unbelievable amount of combinations. Look at our scenario earlier of our hacker who wanted to guess our 100,000,000 possible tokens, he thought that was pretty easy. But now our hacker may need to change his shorts.

    The number of theoretically possible UUIDs is therefore 216*8 = 2128 = 25616 or about 3.4 × 1038. This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs. - Wikipedia

    So our session token goes from looking like this: MYAPP_103_13624879
    To looking like this: MYAPP_106_cd72ce3e98123588-75FEC96D-9137-2EF1-3880EA6C56CD1F4E

    Let's see those side-by-side:
    MYAPP_103_13624879
    MYAPP_106_cd72ce3e98123588-75FEC96D-9137-2EF1-3880EA6C56CD1F4E

    Well, this is just awesome. We've got our secure session token. We're done now. Right?

    Not quite.

    But we'll talk about J2EE session tokens tomorrow.

Comments
Azadi Saryev's Gravatar [Q]
The second thing we can do, is make our session tokens [b]less difficult[/b] to guess. By "guess" I mean [b]less difficult[/b] to find a valid token using a program like Burp Sequencer.
[/Q]

surely you meant "MORE difficult"?..
great series of article, btw! can't wait till the j2ee part... that's what i always use...
# Posted By Azadi Saryev | 6/13/08 2:20 AM
Jason Dean's Gravatar @Azadi - You are correct, that is what I meant.
# Posted By Jason Dean | 6/13/08 6:34 AM
Steve's Gravatar Hey Jason-

I think your series on security is awesome. I have been reading over the past week, and it has really helped me out. Thanks.

Do you know if the server has to be restarted for the new Security Settings (UUID) to take effect? I tried to use this in my app and after dumping the session variables I still get the same 8 digit cftoken.
# Posted By Steve | 1/28/09 5:41 PM
Jason Dean's Gravatar @Steve, someone else just asked me that same thing in a different comment thread. I will copy/paste the response.

"As for why yours is not using UUID cookies, I am not sure. It should not require restarting ColdFusion. But try it anyway. Also, delete any existing cookies you have. If that does not work, email me at jason@12robots.com and we'll set up a connect session and try to figure it out."

Hope that helps. If not, let me know.
# Posted By Jason Dean | 1/28/09 6:36 PM
Steve's Gravatar Hey Jason-

I fixed the problem with Coldfusion not displaying the UUID cookies. I had to restart a Coldfusion service on my client side machine. I went to control panel, administrative tools, services, and restarted the Id_string service. I also restarted my Coldfusion Application Server. I'm not sure if restarting the server helped or not, but restarting ID_string fixed the problem. Thanks again for you help.
# Posted By Steve | 2/13/09 2:06 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner