Pete Freitag Pete Freitag

Session Loss and Session Fixation in ColdFusion

Published on March 01, 2013
By Pete Freitag

I often find myself explaining how the session fixation security hotfix (APSB11-04) might cause session loss under certain circumstances, so I figured it was time for a blog entry explaining it.

Ok, first what is session fixation?

A session fixation vulnerability exists when an attacker can direct the victim to use a specific session identifier. So for example, suppose I say hey follow this link:

Now when you visit this link, if CF allows you to use that new session identifier to maintain valid session, you have a session fixation problem. The attacker can now mirror the session id on his computer and also have access to your session.

How does ColdFusion session fixation protection work?

ColdFusion now checks to see if the CFID/CFTOKEN passed in the url, cookie, form, etc are valid for the current ColdFusion application. If the CFIDE/CFTOKEN passed do not correspond to a valid session in the CF application, then a new set of CFID/CFTOKEN is generated and set as cookies.

So how does this lead to session loss?

The only circumstances I'm aware of which causes session loss is due to having multiple ColdFusion applications that reside on the same domain, with different application names.

So assume I have a domain with two ColdFusion applications /apples/ and /oranges/ each folder has its own Application.cfc or Application.cfm with a different application name (eg"apples" and"oranges").

Now consider the following condition:

  1. Request /apples/
  2. Successfully logs in under /apples/
  3. Makes a request under /oranges/
  4. Makes a request back to /apples/ (they appear to be logged out)

And here's what happens:

  1. User is given a set of cookies CFID=1 CFTOKEN=1
  2. Session variable is set to keep user authenticated with session CFID=1 CFTOKEN=1
  3. CF see's CFID=1 CFTOKEN=1 and says that is NOT a valid session for the Application "oranges", here's a new set of session ids: CFID=2 CFTOKEN=2
  4. CF see's CFID=2 CFTOKEN=2 and says that is NOT a valid session for the Application "apples" here's a new set of session ids: CFID=3 CFTOKEN=3, you are still technically logged in under CFID=1 and CFTOKEN=1 but your cookies no longer correspond to that session, so for all intensive purposes you are logged out of /apples/

So how do you prevent the session loss?

There are a few ways you can do this:

  1. Set a path on the CFID and CFTOKEN cookies so the browser sends the correct cookie to the correct domain, you can do this in OnSessionStart if you specify this.setclientcookies=false. You can see an example of how to set the session cookies in my blog entry on HttpOnly session cookies.
  2. You can set both application names to be equivalent, that is change"apples" to"fruit" and"oranges" to"fruit" this will cause the two applications to also share application and session scopes, so that may not be a good idea if your applications clash on naming.
  3. You can disable the session fixation patch in ColdFusion by adding the JVM argument -Dcoldfusion.session.protectfixation=false to your server. This is a good way to find out if the session fixation patch is indeed causing your problem, or if it is something else. I recently helped a client with session loss, and their problem actually ended up being on the load balancer so it is handy to test using this before making code changes. But keep in mind that when you do this you are giving up some security.

How can I further protect myself from session fixation

This patch doesn't fully protect you from session fixation attacks, you really should rotate session id's after a successful login, and terminate the session on logout. You can do this with two new functions on ColdFusion 10, SessionRotate() and SessionInvalidate().

coldfusion session fixation security

Session Loss and Session Fixation in ColdFusion was first published on March 01, 2013.

If you like reading about coldfusion, session, fixation, or security then you might also like:


The Fixinator Code Security Scanner for ColdFusion & CFML is an easy to use security tool that every CF developer can use. It can also easily integrate into CI for automatic scanning on every commit.

Try Fixinator

The weekly newsletter for the CFML Community


Hi Pete

There's another scenario where the session fixation patch can lead to session loss: conditional manual setting of session cookies. See
by Julian Halliwell on 03/04/2013 at 3:30:30 AM UTC
Hey Pete, I realize that this post (now from several years ago) was about the impact of the session fixation protection (sfp) on unexpected logouts--but I had been wondering with someone else about what exactly it IS that the sfp feature does, in its "protection" sense.

In other words, how does is its intended BENEFIT really work? How does it protect us? You hinted at it when you said here, "If the CFIDE/CFTOKEN passed do not correspond to a valid session in the CF application, then a new set of CFID/CFTOKEN is generated and set as cookies." And fair enough.

But what if they DO correspond to a valid session? I always thought that the real intended benefit of the sfp was to make it (somehow) that someone who used the tokens but was NOT the original user would somehow get rejected.

If there's no session active, then obviously the tokens are of little value (though they are for client vars). But if the session IS active, then it seems this would NOT do something to reject a request from "someone other than the original user" of the session. I really thought that was an expected benefit.

Have you ever considered that? Am I wrong in my assertion? Or might it be just a characteristic you simply didn't discuss here? If you may have any more info, I'm sure many would benefit from hearing it. :-) Or let me know if you think I should reach out to Adobe instead.

by Charlie Arehart on 07/01/2020 at 11:09:18 PM UTC
Hey Charlie, the session fixation attack relies upon the attacker knowing a valid session identifier, and trying to get the victim to use it. For example, suppose someone sends you an email like this:

Charlie, Example Bank has detected an suspicious transfer from your account. If you did not make a transfer please login to cancel it:

Now if Example Bank uses the CFID and CFTOKEN from the url to create a new session for you (as it did before the session fixation patch) then the attacker can just open up a browser and plugin the same CFID/CFTOKEN and be logged in as you. To my knowledge, the only thing the session fixation patch does is rotate the session identifiers if the cfid/cftoken are a valid session for the application. It is still possible for the attacker to create the session first, and then copy / paste a valid cfid/cftoken into the above message - that is why I say this only fixes the problem partially, it is still upto the developer to call sessionRotate after a valid login to prevent the issue all together.

CF doesn't have enough info to be able to tell the difference between the original user and an attacker, if two people have the same valid CFID/CFTOKEN then they will share the session. You can't use IP for this purpose because it may change frequently (especially on mobile), or might always be the same (eg proxies or load balancers that use X-Forwarded-For).

Hope that clarifies it!
by Pete Freitag on 09/10/2020 at 7:24:00 PM UTC
Yep, thanks for that additional info, Pete.
by Charlie Arehart on 09/19/2020 at 4:21:11 AM UTC
Risking bringing up an old thread again. :-) The organization I work with recently had an ethical hacker flag a site for session fixation. We're using CF2016, and using J2EE session management. Everything I'm finding in my research on this seems to indicate that this mainly affects CFID/CFTOKEN and not jSessionID. Am I missing something? Is this a false-positive from the ethical hacker? Thank you.
by Matt Barrick on 01/22/2021 at 7:22:34 PM UTC
Hey Matt - It's hard to say without more details. A good way to prevent session fixation though is to rotate the session id at login, and invalidate the session at logout. You can use the sessionRotate() / sessionInvalidate() function for that if you use CFID/CFTOKEN sessions, or if you use j2ee sessions you can use this technique:
by Pete Freitag on 01/22/2021 at 7:58:35 PM UTC