[Looking for Charlie's main web site?]

"Use UUID for cftoken" in ColdFusion Admin does always not block use of 8-digit cftokens

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
This topic came up on a discussion list, in the context of a larger thread, and I wanted to share here what I said there.

As an update since I first wrote this, it turns out this issue may or may not affect you depending on a couple of variables, which I will discuss, with a prefix of "update:" below. But don't dismiss this thinking you are not affected. I would propose that still far more CF servers may be exposed than not, as I will explain.

The CF Admin has (for several releases) offered an option called, "Use UUID for cftoken" (in the "Settings" section), and it's been intended as a security measure. Its purpose is to cause CF to use a UUID value (a long, complex string of numbers and letters) for the CFTOKEN cookie (and session variable) that CF generates, versus what used to be a simple, 8-digit value. This cookie, along with the simpler and incrementing CFID, is used to connect users to the session and/or client scope values created for that user in CF code.

Some may be surprised to learn, though, that while this setting DOES cause CF to *create* such UUID-formatted CFTOKEN values for requests that do not already present a CFTOKEN cookie, it does NOT necessarily cause CF to block any continued use of such simple, 8-digit cftoken cookies.

In other words, browsers which had visited your site before you turned on "use uuid for cftoken" would still send the 8 character cftoken they already had, not a uuid, and that could be accepted as valid by CF, even with that setting on, under certain conditions. (And the user will not be sent any new cftoken cookie in a UUID format, in CF's response, in those conditions.)

There's good and bad news related to this fact, which I will elaborate on below.

Update: Since writing this entry, I learned of a couple of factors that influence if and when this is a problem.

  1. It turns out that if you are using CF10, or CF9 or 8 with the "session fixation" hotfix (APSB11-04), then the problem only happens until you restart CF. The Admin does not currently warn you of this, so beware that you will have the exposure below until you do restart. (If you have added one of the later security hotfixes or cumulative hotfixes that came out since then, then you have gotten the fix.) This fix causes CF to create a new UUID-based CFTOKEN, if you turn on this feature at least (and after a restart) when a browser presents a previously created 8-digit cftoken.
  2. On the other hand, even if you are running CF 10, or running 8 or 9 and HAVE applied that hotfix, note that if you TURN OFF that fixation protection (by adding the -Dcoldfusion.session.protectfixation=false value to your jvm.config, as discussed in that technote), then you are back to the state that I discuss below.
  3. And of course, if you are on CF 8 or 9 and have NOT yet applied that APSB11-04 hotfix (or a later cumulative one that includes it), then you are indeed still vulnerable.

So that leaves still many people who could be affected by this. Even if it seems you may not be, you may want to continue reading this entry to understand what the issue is about, for you and others who may be impacted by it.

[....Continue Reading....]

Comments
Charlie, actually I don't think a restart is necessary in all cases, if the session timeout occurrs then it should have the same effect as the restart (clearing CF's internal registry of valid session identifiers). I would try your example using a session timeout of 1 minute to verify (I haven't had a chance to test this yet).
Sure, that makes sense, and I think it was covered by my observation above that all this was true, with respect to sessions, "at least until their sessions timeout", once one had changed the uuid for cftoken setting.

So yes, I agree that the issue would solve itself in those situations even without a restart.

BTW, I meant to add clarification, when I updated the entry with the "update:"s above, that those were driven in fact because Pete had pointed out to me (in an email conversation we had when I pointed this out to him) that the issue would indeed resolve itself (for those with session fixation protection in place) if one did a restart, so I do thank him for that! :-)

But let's make sure no one misconstrues these comments: the rest of the issues are still of concern for the other scenarios I described.
Hello Charlie,

Few days before I faced some issue related to ColdFusion server spiking by the help of your articles I able to solve that. So, thanks a lot for that.

Now, I just want to know do you have any kind of book or reference for ColdFusion Server monitoring and ColdFusion Coding best practices which will help me to dig more on that part.
@Upendra, thanks for the kind regards. As for books, there are none devoted to the topics you mention. But as for monitoring, if you may mean the ColdFusion Enterprise Server Monitor, I can point you to a 4-part series of articles I did on that (about 40 pages, so almost a book), and it's about the only substantial coverage of the tool:

http://www.carehart....

But if you mean not just that monitor itself but monitoring ColdFusion in general, note that I have many blog entries here on FusionReactor and SeeFusion as well. See the categories to the right here (including one on "monitoring", generically).

And as for troubleshooting in general, I have a resource, cf911.com, which is devoted to organizing CF server troubleshooting resources.

As for CF coding best practices, that's a unicorn that many chase but it seems elusive. I myself would not have any recommendations or references to offer with respect to that.
Hey Charlie. I think I'm in the right place.

I have not yet applied Hotfix 4, but after installing Hotfix 3 one evening, I checked the UUID box, restarted CF and went about my business. The next morning all hell broke lose and my office phones were ringing off the hook. Everyone had the same issue, they couldn't log in to their web applications.

It was easy to see this was the cause because we hadn't done anything else. However, I didn't want to switch it back, as that would be a step in the wrong direction. So after lots of troubleshooting we started having customers remove all cookies from their machines and then all was well.

On top of all of this, we have a few applications that also jump between machines, for reasons I won't go into here, and the alternate server had not had the UUID box checked. And that was causing major problems and took us a while to figure out why.

I have not checked this box on a few other machines because we host about 2500 Cold Fusion Apps on those machines and I don't want to cause mass chaos.

My question to you at this point, after searching on Google for over 4 hours trying to find someone in a similar situation with no luck, is if I check the UUID box, restart CF9 and then go manually purge my client variable database completely, should this keep things running smoothly the next morning?

I'm assuming that if the users cookie values are not found in the Client Vars database then new one's will be created using the new UUID value. Is this a correct assumption?

Thanks for all of your blogging. My CF servers are locked down super tight now. Once I get passed this issue I'll be installing Hotfix 4.
# Posted By Travis | 7/31/13 12:05 AM
@Travis, a few questions:

First, when you refer to "hotfix 3" and "hotfix 4", do you really mean individual security hotfixes whose jar names start with "hf" and end in 0003.jar or 0004.jar? or might you mean cumulative hotfixes, which start with chf? Could be significant to this question, but if nothing else it's important to always be clear on whether one is referring to an individual hotfix, a cumulative hotfix (which groups those), or an individual security hotfix.

Second, you say you made two changes: applying the hotfix and ALSO turning on the cftoken as UUID. Why did you do the latter? There's no hotfix that indicates that one should change that value, so I'd wonder why you did both in one night. It's always risky to change more than one thing at a time, of course, because it's hard then to know the cause if something breaks.

Third, you say you "didn't want to switch it back, as that would be a step in the wrong direction". So you didn't even try it, in the face of these problems?

Finally, and most important, you say that the problem is that folks "couldn't log in to their web application". OK, so then should we assume you were using session variables?

If so, I would propose that the problem was not this cftoken as uuid setting, but rather the "session fixation" feature which I discuss above, as having been added by one of the security hotfixes.

Did you try adding the -Dcoldfusion.session.protectfixation=false feature in the jvm.config? That may have resolved your issue (though granted, it then opens you back up to the session fixation problem that the feature was supposed to protect against). You can find out more about it here: http://www.petefreit...

Now, there's a bigger discussion that's not really warranted here: why it is that when this feature is turned on (added by the hotfix and not disabled as above), people find that some (not all) apps and some (not all) browser/users find that they "lose" their session. It has do to with the kind of cookies created after this particular hotfix is implemented. You will generally find that those with the problem ("losing" their sessions) have duplicated cfid and cftoken cookies. the reason for the duplication, and the reason for the impact on sessions, is not well documented anywhere that I have seen. Perhaps I may some day.

Anyway, Travis, give the above some thought and if you want to offer answers and an update, or any follow-up questions, then I or someone else may have more to share in reply.
Hello again Charlie. Sorry for the delay and thank you for responding.

So, I'll start by answering your questions from the top...

I am running version 9.0.1 with hotfix chf9010004.jar.

I turned on the UUID function because I had to in order to pass a PCI compliance scan test. And didn't want to revert back since I suspected that all of my cftoken values would get messed up if I then turned it off. Also, I didn't do them simultaenously. I did the hotfix first and tested some session heavy sites to make sure all was well and then I turned on UUID and tested again. Everything seemed fine.

However, after these changes, suddenly we were getting random calls from customers complaining about not being able to log in. And upon further investigation I was able to confirm that the session was in fact active in their browser. After looking deeper I noticed in the session variable that randomly, the UUID value would change but the appended UUID session value for the CFTOKEN was not updating to match it.

And yes, we are using session variables and client variables for application settings. Giving each domain a unique application name.

I have NOT added the JVM argument "-Dcoldfusion.session.protectfixation=false" to my CF settings. Would this be a first step in your opinion.
# Posted By Travis | 8/18/13 6:38 PM
Also, just so you know, I do have the "-Dcoldfusion.sessioncookie.httponly=true" JVM argument added. Just in case it matters in your thought process.

Also, since my last post I have signed up for hackmycf.com and it's awesome! What a great resource and tool.
# Posted By Travis | 8/18/13 6:42 PM
@Travis, yes, I would recommend you address the session fixation issue, since that was added as part of the CHF (though it's technically from a couple of years ago, many only "got it" when applying a CHF more recently for the first time.)
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting