Even if you have JEE sessions enabled, CF will continue to set CFID and CFToken cookies unless you tell it not to. It does this for use with the CLIENT scope.
If you are not using the client scope for anything then you can safely tell CF to stop setting those client cookies.
If you are using Application.cfc then add this to your pseudocontstructor area:
<cfset this.setClientCookies = false />
If you are using Applicaiton.cfm, then I begrudingly tell you to add this to your <cfapplication /> tag
<cfapplication ... other settings... setclientcookies="false" />
If you are using the client scope then you may be out of luck and will need to reimplement whatever you are using the client scope for using the session scope instead.
Thanks, I'll give that a try.
That worked so thank you very much.
I just got alerted of the same issue.
So wait...you're saying that in order to truly be within PCI compliance, you cannot use the client scope at all? That would really suck. What's really nice about the client scope is that you don't have to worry about sticky sessions in an environment with multiple web servers (as long as they have a common database behind the scenes). That's the scenario I have set up, and I cannot imagine that fundamental a change to my architecture. Is there really no other way?
Personally, I think that this warning is a false positive. CF gets flagged because CFID is not randomly generated, however CFToken (in CF9 and higher) is random (at least partly). I cannot say for certain if the combined to values are random enough for PCI compliance, that is something you would have to ask a PCI expert.
But if it is required that there are NO warnings in the automated test, including false positives, then no, you cannot use the client scope and be PCI complaint.
Remember that automated tools are stupid. It is only recognizing that the CFID value is not random, even if the CFToekn value is. It does not understand that the two are related and that both pieces are rquired as part of the session token, so even if the two combined are sufficiently random, the test will always fail due to the lack of randomness in the one part of the token.
P.S. You should also keep in mind that the client scope sucks. It may seem convenient, but it has enough drawbacks that it is probably not worth using. http://www.dopefly.com/pages/ColdFusionClientVariablesFinalNail.cfm
Actually, thinking about this, since CFID and CFToken are NOT being used for session management when JEE Tokens are enabled, I would think that they could safely be ignored in the PCI scan for session vulnerabilties. They are really just two cookies that happen to have the same name as CF Session Tokens (when JEE Tokens are not enabled) but they have nothing to do with session management.
That said, is the CLIENT scope a secondary form of session management? If those cookies need to be protected in the same way as session tokens, then you are back to having issues with PCI.
I have submitted a request to Adobe to clarifiy if the CFID + CFToken combination are suffiecient for PCI compliance and to find out if CFID can be made into a random LongInt instead of the not-random tiny number that it is. That of course, would not help you know, but perhaps the first part would.
Personally, I use the client scope instead of the session scope so that I don't have to worry about sticky sessions. That has always worked out nicely for me.
I read that article you referenced, and it's got some interesting stuff. In particular, I have seen the client scope database tables not purge as they're supposed to. And the stuff about preparing, executing, and then unpreparing SQL statements on each request is alarming, if true.
However, I have to say that I have never, ever, ever, ever had performance issues due to client variables. Not once. Whatever performance hit my application may incur from using client variables has, to this point, been completely dwarfed by the performance of the application itself. And, c'mon, the stuff about being lazy because you don't want to spend precious engineering time worrying about something like session management (which is never going to add value to your product) rather than coding something actually useful to your end users...that seems overly harsh to me.
I completely agree that storing client vars in the Windows Registry is bananas, as is the defualt 90 day purge limit (though as of CF 9.0.whatever, the default is 1 day, 7 hours, so clearly they've made some changes since this article was written). But I'm loathe to throw away client-based management.
I think, getting back to the issue at hand, that this may be a false positive. CFID is sequential, but CFTOKEN is not; that should really be the end of the story. I'll see if McAfee will listen. (-;