[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.

The good news: users can still access their session/client scope data

So the good news in this behavior is that users who had been to your site before the change was made would again continue to use the cfid/cftoken pair they were previously sent, and this would be needed in order to connect their browser to any existing session or client variables (client repository records) which may have been created for their given cfid/cftoken pair before you made the Admin change.

The bad news: bad guys could still try to hijack sessions and client variables

The bad news is that since the simple cftoken values are still acknowledged after the change, it means that while good guys (users) can still use them to access data that may exist for them on the server, it also means that bad guys could still try to "hijack" sessions (or client variable data) by passing in simple values, if in fact they could find session or client data for such a "simple" cfid/cftoken pair that may exist in the server.

For more on the concept of session hijacking, which this feature was specifically added to address, see such entries as those on from wikipedia, OWASP. Here also are discussion of CF session hijacking from 2005 ("Mister Ruthsaria"), 2007 (Dave Ferguson), and 2008 (Jason Dean), so the discussion of CF session hijacking is nothing new.

But I've not seen anyone else discuss this matter that existing simple cftokens continue to be acknowledged even after this setting is enabled.

Before you freak out

As with any discussion of security, it may set some people in a panic. Sometimes it's warranted, sometimes, not so much. I am sharing info to let you decide for yourself.

For instance, the risk of hijacking (because of possible existence of simple cftoken values) depends on users having visited your site and your code having created session for them, all while they passed in the simple cfid/cftoken pair.

Once you change that admin setting, you would hope that the number of such "simple" cfid/cftoken pairs in use at any one time will decrease, as new users (who had not visited before) will get new UUID cftokens. But sessions with the simple values as keys will still exist when users still using them do visit your site, at least until their sessions timeout.

This problem is a more disconcerting with respect to client variables, since those live in the client repository (by default) for 90 days since previous use.

And to be clear (lest some people be scared without fully understanding me), this is all predicated on your having CFML code on your server that accesses the session or client scopes. I'm not talking about some vulnerability that allows hackers to somehow "magically" get access to session and client variables. Again, read up on session hijacking before getting overly concerned. And if you don't have code that uses client variables, then you have no need to worry about any implication for client variable hijacking.

Even so, I think this news (that the setting only controls creation of new cftokens, not continued use of existing simple one) may well be a surprise for some, and that's why I'm writing. I will also notify the Adobe CF and PSIRT teams, so they are aware of this. I don't know that this warrants a security alert, and there may be nothing that Adobe can really easily do (as I'll explain in a moment). I think it's just something that people ought to be aware of, if they were relying on that setting to "totally protect them from easy session/client hijacking".

Bottom line: the "Use UUID for cftoken" setting only controls the *creation* of new UUID cookies. It does not enforce a rejection of existing 8-character ones (because of that need above for real users to still be able to access existing client/session data.)

Want to test for yourself?

Maybe you're the "show me" kind of person. You can test this yourself. You just need some tool that allows you to delete cookies in your browser (more in a moment). You'd want to:

  1. Look at the CF Admin to see what the "use uuid for cftoken" setting currently is. If it's off, keep it off. If it's on, turn it off (we'll turn it back on in a moment.)
  2. Create a new folder in whatever web-accessible directory you use for creating test pages
  3. In that new folder, create an application.cfm that has this:
    <cfapplication name="cftokentest" sessionmanagement="yes" clientmanagement="yes">

    We're creating a new folder with its own application.cfm so that we don't clash with any existing application.cfm or .cfc you may have in the directories above it.
  4. In that new folder, create a page that does a CFDUMP of the session and client scopes, and the CGI if you want, for good measure. Let's call it dumpvars.cfm:
    <cfdump var="#session#">
    <cfdump var="#client#">
    <cfdump var="#cgi#">
  5. Visit dumpvars.cfm
    (If you get an error running the following pages because you have no default client storage defined in your Admin, you could add clientstorage="registry" to the line above. It's not wise to use the registry for client variables regularly, but that's for another blog entry. And while you could use clientstorage="cookie", it could confuse matters for this entry.)
  6. If you had turned off the "use uuid for cftoken", you should see an 8-digit cftoken. (If you do not, it means you already had one in your browser, which proves my point.) But let's delete that cookie for now. Use whatever tool you have to delete the cookies.
    (While most browsers have an option to clear "all" cookies, I'd recommend finding a finer-grained approach, to delete only those for a given domain. Any of several tools can help, including some built-right into browsers, as I discuss in a blog entry, Need to solve browser problems? Did you know most modern browsers now have built-in developer tools?. I also point there to alternative tools like firebug, charles, etc.)
  7. Refresh the page and confirm that you do now see (or still see) an 8-digit cftoken.
  8. Create a page to update a variable in the session and client scopes. Let's call it setvars.cfm:
    <cfset session.fname="yourname">
    <cfset client.fname="yourname">
  9. Visit dumpvars.cfm again, and you should see the values you just set.
  10. In the CF admin, turn on "use uuid for cftoken".
    Update: here is the point where, if you DO have the APSB 11-04 or later hotfix applied, and do not restart CF, then you will still see the behavior I discuss here, and the next will show that the old 8-digit cftoken is still used, at least until you do next do a restart. Since many may not know about this, it's is at least a temporary vulnerability.
  11. Visit dumpvars.cfm again, and you should see no change. The same cfid/cftoken is used, and the values you just set are still there. This shows that changing that setting does NOT block contiued use of simple cftoken values.
  12. Clear the cookies again, and refresh the dumpvars.cfm page. You should now see that you have a new cfid/cftoken pair, and the cftoken is now a UUID (which shows that you do NOT need to restart CF after turning this setting on). But note that the variables you set are gone. The point is, you have a new CFID/CFTOKEN pair, and can therefore no longer access the variables created for use by that previous cfid/cftoken pair. But in this case, it's what we'd expect because you did in fact delete the cookies.
  13. If you had originally had "use uuid for cftoken" turned off, you may want to turn it back on (to revert to what you were using beforehand). But then it is in your interest to use that setting for protection. And as this entry shows, it will not affect existing clients and client/session variables. (But do note that if you have code that manipulates the cftoken value, such as validating it, storing it in a database of your own, etc. then beware that it will now be a much longer value, as a UUID, than it was before when this setting was not enabled.)

So there you have it.

What could be done, going forward?


  • Again, if you are on CF 10, or on CF 8 or9 with at least that APSB 11-04 or later security hotfix applied, then you are covered, at least as long as you restart CF after turning on "use uuid for cftoken".
  • But if you *are* on CF 10, or are on CF 8 or 9 with at least that APSB 11-04 or later security hotfix applied, but you have turned off the sessionfixation protection as I discussed at the opening of the entry, then you will remain vulnerable to this until you turn back on that session fixation protection.
  • And of course, if you are on 8 or 9 and have not applied that security hotfix or above, then you will remain vulnerable.

And now that I realize that the new sessionfixation protection will cover us, at least if we restart CF after making the change, my proposal of other possible fixes is now moot, so I will strike them out.

I suppose one could argue that an option should be added that forced CF to reject any such 8-token CFTOKENs. I'll leave it to others to raise a feature request for that, or point out if it already exists. (And someone may well have raised this as a "bug" already, but if the CF team regarded it as a security issue, it would be marked private and you couldn't see it.)

If Adobe were to add the an option to reject simple cftokens, I'd asset that should remain just an option, though, and not become a default if uses "use uuid for cftoken". Again, rejecting existing cftoken values would mean loss of connection to existing client and session data for users still using the old cfid/cftoken pairs. That would not likely be what everyone would want to happen! (And the fact that it does not is why I think this issue has remained quietly unobserved for so long.)

Someone might propose that still another option would be to have CF swap out the old cftoken for a new one, in a transparent way, just like the new sessionrotation feature in CF10 does change out tokens on the fly to address session fixation issues. Unfortunately, this would still require CF to allow a request to come in with old "simple" cftokens, so the hijacking vulnerability would be there, it seems. But maybe folks on the CF team (or a reader here) will see some opportunity I don't.

And indeed, I think this thorny challenge to solving things is why this problem was never solved. There doesn't seem any easy way to remap existing users to their existing session/client variables while also blocking access to these simple cftoken values.

It pays to watch the incoming cookies, when trying to understand session/client variable challenges

Finally, I'll note that one reader on the discussion list in question did acknowledge that this situation did also explain an odd behavior he had noticed. I suspect it could, especially for those who may do manipulation of these cfid/cftoken values, especially if they didn't fathom that this was happening (simple CFID values were still being accepted).

This is why I always stress the value of dumping the CGI scope, which shows what the *incoming cookies* are, when trying to debug problems with respect to session or client variables. So often people will say "my users keep losing session variables", but then they may not notice that for some reason the user is not passing in any cfid/cftoken (or jsessionid) values. "No tickee no washee", as the old saying went. But if you dumped the cookie scope instead, especially after your application.cfc or .cfm ran (specifically cfapplication within application.cfm), then the cookie scope would show values created by CF, even if none came in one the request.

Hope something above in all that helps someone.

(PS. I did my testing of this on CF 9.0.2 and CF10, getting the same results.)

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
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).
# Posted By Pete Freitag | 7/10/13 7:38 PM
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.
# Posted By Charlie Arehart | 7/10/13 10:27 PM
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.
# Posted By Upendra Roul | 7/26/13 1:43 AM
@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:


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.
# Posted By Charlie Arehart | 7/26/13 9:59 AM
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.
# Posted By Charlie Arehart | 8/1/13 12:04 AM
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.)
# Posted By Charlie Arehart | 8/19/13 1:00 AM
Copyright ©2020 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