Session Loss and Session Fixation in ColdFusion
By Pete Freitag
I often find myself explaining how the session fixation security hotfix (Fixed in ColdFusion Security Update 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:
http://example.com/index.cfm?CFID=1&CFTOKEN=2
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 this.name="apples" and this.name="oranges").
Now consider the following condition:
- Request /apples/
- Successfully logs in under /apples/
- Makes a request under /oranges/
- Makes a request back to /apples/ (they appear to be logged out)
And here's what happens:
- User is given a set of cookies CFID=1 CFTOKEN=1
- Session variable is set to keep user authenticated with session CFID=1 CFTOKEN=1
- 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
- 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:
- 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 specifythis.setclientcookies=false
. You can see an example of how to set the session cookies in my blog entry on HttpOnly session cookies. - You can set both application names to be equivalent, that is change this.name="apples" to this.name="fruit" and this.name="oranges" to this.name="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.
- 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()
.
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:
- Scope Injection in CFML
- J2EE Sessions in CF10 Uses Secure Cookies
- Latest ColdFusion Security Updates - September 2024
- Fixinator fixes unscoped variables
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
CFBreak
The weekly newsletter for the CFML Community
Comments
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.
Thanks.
Charlie, Example Bank has detected an suspicious transfer from your account. If you did not make a transfer please login to cancel it: https://bank.example.com/login?cfid=x&cftoken=y
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!
There's another scenario where the session fixation patch can lead to session loss: conditional manual setting of session cookies. See http://cfsimplicity.com/4/coldfusion-security-hotfix-changes-session-behaviour