Description: Web Server Uses Non Random Session IDs Synopsis: The remote web server generates predictable session IDs. Impact: The remote web server generates a session ID for each connection. A session ID is typically used to keep track of the actions of a user while he visits a web site. The remote server generates non-random session IDs. An attacker might use this flaw to guess the session IDs of other users and therefore steal their session. See also : http://pdos.csail.mit.edu/cookies/seq_sessionid.html Data Received: Sending several requests gives us the following session IDs : CFID=896744 CFID=896745 CFID=896746 CFID=896747 CFID=896748 Resolution: Configure the remote site and CGIs so as to use random session IDs. Risk Factor: Medium/ CVSS2 Base Score: 6.4 AV:N/AC:L/Au:N/C:P/I:P/A:N

We are using J2EE session variables which I though was the more secure option. Is there something else you have to do to guarentee that the Session ID's are non random or is this the Compliance test picking up on a false positive?

P.S. It's a recent migration to CF10, don't know if that has anything to do with it.

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.

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. (-;