CF: Session Hijacking

ColdFusion uses two unique values to keep track of user session information. These values are CFID and CFTOKEN. They are stored as cookies but can also be passed along the URL and inside POST data.

Session variables are a place to store information specific to the user and to the current session (such as whether or not a user is logged in).

It is possible to hijack a user’s session by supplying the correct CFID and CFTOKEN values to the server, either on the URL, or wherever else you want.

The two numbers combined represent a space of 10^15 numbers. Average brute force will take half that amount, so 10^15/2. Figure 100 attempts per second, and the average time it would take to brute force is in the neighborhood of 150,000 years.

There’s the 1 in a jillion chance someone might guess a correct CFID and CFTOKEN, but that doesn’t really worry me much.

Your more likely to see someone hack your application by doing a little packet sniffing (or looking over someone’s shoulder) and capturing the CFID and CFTOKEN that way.

Packet sniffing you can curb by going over SSL with your application. Over-the-shoulder attacks can be stopped by not passing the CFID and CFTOKEN values on the URL (which CF does with cflocation tag by default… go figure).

If the user has a virus on their machine passing out their cookies, well that user has a bigger problem than having their session hijacked.

So how do you protect against session hijacking? You store the IP address as a session variable. Compare the IP in the session variable to the user’s IP (stored in cgi.remote_addr) and if they don’t match, you’ve got a hijacking attempt.

… But there’s a catch.

AOL, for example, uses a proxy server for their packaged browser. This means everyone comes from the same IP address. Not cool. Now AOL users can simply go into their browser settings and kill the proxy config and they’ll surf using their own IP, but can you really ask users to do that for every little application we have using session variables?

Also AOL users won’t be the only ones behind a proxy server.

And if you have session timeouts set to days, dial-up users and any other user on a network with shared IP addresses will eventually get an IP address of a former user. And they might be able to get into the application that way.

So what can you do? Not much. You won’t ever be 100% certain in your security. It’s all about managing risk. In this case, you’re at a fairly low risk with hijacking if you’re comparing IP addresses.

But here’s what I do to take it 1 step further.

Combine the user’s IP address and browser string (cgi.http_user_agent) into a single string. Then MD5 hash the thing. Store that hash as a session variable. Recalculate and compare hashes as the first step in any user request (in other words: put this logic in your application.cfm file, and put it up at the top). And that should protect you well enough. The browser string provides a little extra security in the event of proxy users hitting the site.

Also keep your session timeouts to a low value (30minutes.. 2 hours MAX, unless security isn’t a big issue for your application).

When you detect a hijack attempt, you might not want to kill the session because the legit user also gets locked out. You can reset CFID and CFTOKEN on the user with the CFCOOKIE tag then redirect the user to the enterance page.