jSessionID, CFId/CFToken-Which is predictable?

I have results from our the new and improved PCI scan and it comes up with one Medium risk vuln.

Description: The remote web application is using predictable cookie-based session IDs. Ideally, session IDs are randomly generated numbers that cannot be guessed by attackers. If the session ID is predictable, an attacker could hijack an active victim's session, allowing the attacker to interact with the server as though they were the victim. If the session ID is used to track the state of authentication, the session ID of an authenticated user could be guessed, bypassing any need for a username or password. In the case of this server, the session ID was found to have an insignificant number of changes between session IDs, which makes guessing very easy.
Remediation: The software needs to be either configured or modified to generate random session IDs.

Assuming I'm getting flagged because of cfid/cftoken predictablility I've setClientCookies = "no" and clientmanagement="no" and restarted the service and everything seems to be working with jsessionids alone... are there any pitfalls to watch out with not using cfid/cftoken?

I currently have enabled Use J2EE session variables

basic question before I pay for another scan is:

I was under the impression that jsessionids were the most secure and a better alternative than cfid/cftoken. Is that not the case?

Note: The flagged scan occurred before I made the client variable changes to the application.cfm (so I had both jsessionid and cfid/cftoken being set) As of now only jsessionid is being set
LVL 36
Who is Participating?
SidFishesConnect With a Mentor Author Commented:
"From what I've read, it doesn't write a physical cookie (can you verify?)"

Using web developer toolbar in firefox I can see that my site is setting a physical cookie

Value      f03010e3214b683b398057647a68471d713d
Host       www.mysite.com
Path      /
Secure      No
Expires      At End Of Session

prior to making the changes to setClientCookies and clientmanagement i was also getting

Value      1015669
Host      www.mysite.com
Path      /
Secure      No
Expires      Wed, 08 Jul 2037 22:25:12 GMT

Name      CFTOKEN
Value      3796a2e90e4d96a-D122AD5D-1143-CEFE-5A42154B679FC06F
Host      www.mysite.com
Path      /
Secure      No
Expires      Wed, 08 Jul 2037 22:25:12 GMT

as you can see the cftoken is quite secure (unless there's an issue with java uuid creation which would probably bring down the internet so we won't worry about that)

gd - I've thought about encryption but after reading up on this issue, i'm tending to think that it's probably not necessary

#hash('f03010e3214b683b398057647a68471d713d')# = AAFD3B1194CE755F0DBA15309A25528A

neither are guessable in any realistic manner

If I was using cfid/cftoken I'd probably do it. Ben Nadel's got a script showing how for those interested http://www.bennadel.com/blog/785-ask-ben-hiding-encrypting-coldfusion-cfid-and-cftoken-values.htm)

I think, however that the J2EE solution gives me the security I need and puts me back in compliance.
I'm sure it's that cfid value that is/was causing the flag. As I said, I'll post the results of the scan with only jsessionid being set.

dg ... well at least you're now a bit more -educated- ;)

As always... a good discussion.

maybe I'm off base but ...
I ONLY use session.UserID which is set by the app upon successfull login
By default session.UserID is set to a value of 0
and all queries or sprocs that pull user data is fed session.UserID
and I've tested and tested to try and find a way to hijack someones session.UserID and I could not do it.

good luck ...
SidFishesAuthor Commented:
actually I'm not talking values -I- set with the app but the cookies generated by CF when sessionmanagement is enabled...

afaik, cf uses the cookie (either jsessionid or cfid/cftoken combination) to track sessions on the server





and this is the only thing that gets passed back and forth as the identifier

I can see how


could be easily predictable, however I do have use uuid for cftoken set on the server so my

so it was looking like


to me the jSessionid and cftoken using uuid do not seem like they could be the issue. I'm thinking the PCI scan is looking at cfid alone (which is easily guessable) and not in combination with cftoken, which is how it is always used.

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

ok - i understand
could you explain "what" might be at risk if someone grabs someone elses cfid and or token?
i'm thinking that even though they are passed by the app and can be stolen - if the app doesn't use them then ???

maybe I don't get it
or maybe the pci scan is assuming that the app is using these values
SidFishesAuthor Commented:
if I looked at a website cookie set on my machine and the seed is not randomized sufficiently (which the scan apparently checks by visiting several times and comparing the cookies)

If a bad guy changed the cookie, they could potentially view the entire session of a different user

bad guy: CFID=7308&CFTOKEN=17386890

innocent random user: CFID=7308&CFTOKEN=17386895

since this is the only ID that the server uses to verify the session, if bad guy modifies his cookie just by incrementing the last digit in 5 tries he will be able to load everything that is contained in the session of innocent random user and CF couldn't tell the difference

now this was a known vuln in earlier versions of CF and the were supposed to have fixed the number generator for cftoken and with the option of using a uuid I can't see how there would be a security issue

what i think is happening is that I'm getting flagged for CFID being not sufficiently random even though that is not really important since it is always used iin conjunction with cftoken (and mine was set to uuid)

Also, since I'm using jsessionid, cf isn't using the id/token pair anyways...but it's still flagged as the scan can't know that. That's why I turned off setClientCookies and clientmanagement.

SidFishesAuthor Commented:
OWASP says

Best practice calls for J2EE session management. In the event that only ColdFusion session management is available, strong security identifiers must be used. Enable this setting to change the default 8-character CFToken security token string to a UUID.


( i knew that I'd read that somewhere...)

So sounds like I'm on the path of goodness...

I'll keep the q open and post the results of the next scan...

JSessionID is a more elaborate identifier, so its much less likely to be guessed.  

Also, JSessionID is a per-session variable that's temporarily stored in the client browser.  From what I've read, it doesn't write a physical cookie (can you verify?)   One feature of this is that when the browser is closed, the session is terminated.

But if you really want to secure the session more, you can hash the session (together with a secret phrase) and store that in session or browser cookie.  Check the session against the hash to ensure it hasn't changed.  (Similar as encrypting and decrypting really).  

now i understand what you are saying sid
sorry that i'm uneducated in this matter
Not entirely sure - but I think the "At End of Session" for expiration may mean that the cookie is not physically set, but is a session or browser based cookie...

Value      f03010e3214b683b398057647a68471d713d
Host       www.mysite.com
Path      /
Secure      No
Expires      At End Of Session   <<<<<<<<<<<   Browser Cookie ?

SidFishesAuthor Commented:
you could be right...since FF3 uses sqllite for cookie mgmt now, I can't actually viewing a physical cookie location...

SidFishesAuthor Commented:
fyi, the scan was clean after preventing the use of cfid & cftoken.... looks jSessionids are the only way to go for PCI DDS compliance

thx to both
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.