Skip to main content
Participant
August 3, 2012
Question

Bad Cookies after Upgrade to CF 10

  • August 3, 2012
  • 1 reply
  • 823 views

We recently upgraded our servers from Win server 2005, IIS 6, CF 9 to Win Server 2008, IIS 7.5, & CF 10. The new servers ended up with the same IP, etc as the old. We have had a problem where cookies that were set in browsers hitting the old server are causing problems when hitting the new server.

The symptoms of the problem are that the session is renewed on each page load - so for login attempts, and other things involving session storage can never happen. We have found that in order to "fix" the problem we have to have our end users delete ALL cookies, and then things seem to be working fine.

We are just guessing that somehow the browsers are being tripped up/confused by the fact that the existing cookies appear valid, since it is for the exact same domain/etc, but that the difference between IIS 6 vs IIS 7.5 and CF 9 vs CF 10 are enough to confuse it.

Anyone have any ideas what we can do short of forcing alll of our users do manually delete all of their cookies? (Nightmare).

Thanks.

This topic has been closed for replies.

1 reply

Charlie Arehart
Community Expert
Community Expert
August 20, 2012

I don’t know for sure, but I have a guess: I think this is one of those kind of problems that are fixed by your adding a jvm argument that turns off “session fixation” security, which was added to CF 10 added—and which was made available as well for CF 8 and 9, but perhaps you had not applied it (and experienced the impact of the fix, and the need to “turn this new protection off”) before you made the move to 10.

The argument (and a brief discussion of the issue) is mentioned in the technote http://helpx.adobe.com/coldfusion/kb/security-hotfix-coldfusion-8-8.html. As it notes, you can add:

-Dcoldfusion.session.protectfixation=false

By adding this in the JVM args for CF (whether in the CF admin Java & JVM page, or in the jvm.config) and restarting CF, you will indeed be turning this particular “improvement”, but if that improvement is what’s making your apps break, then this is indeed an idea of “what we can do short of forcing all of our users do manually delete all of their cookies.”

If you have someone with whom you can do a test, you should know fairly quickly whether it “fixes the problem”. I appreciate that the next natural question is “well, what do I then LOSE in terms of protection by applying this removal of protection?” That’s not well-discussed in that technote, but you can read about session fixation in general here: http://en.wikipedia.org/wiki/Session_fixation and https://www.owasp.org/index.php/Session_fixation.

And I’d note that this “addition of session fixation protection, with the option to turn it off” is not unique to CF. Here’s an article written for Tomcat users explaining it as well: http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection, and even here’s one on asp.net: http://software-security.sans.org/blog/2009/06/24/session-attacks-and-aspnet-part-2

But back to your original question, I *hope* that this may be the quick and easy solution to your challenge. I didn’t want to just offer a one paragraph answer to give you (and other readers) additional perspective needed to appreciate the suggestion.

Let us know if it helps.

/charlie

/Charlie (troubleshooter, carehart. org)
Participant
August 20, 2012

Thanks for the response Charlie. We figured out a solution to our problem, and it is related some to what you wrote about.

As I was working through trying to figure out the problem I finally figured out that we were picking up multiple CFID cookies (we are a university with multiple CF servers). It only started after we upgraded to CF 10, so maybe it did have to do with the session fixation setting. We noticed that browsing to some sites within our university system we were picking up a domain cookie for *.domain.edu. Then when we browsed to our server, we would pick up another for sub.domain.edu. Our fix was very simple however, since we don't access or utilize CFIDs directly, we simply switched to use J2EE sessions.

This fixed our duplicate (and in some cases triple) CFIDs from messing things up.

Again, thanks for responding.