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
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
ASKER
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
ie:
JSESSIONID=f03010e3214b683
or
CFID=7307&CFTOKEN=17386890
and this is the only thing that gets passed back and forth as the identifier
I can see how
CFID=7307&CFTOKEN=17386890
could be easily predictable, however I do have use uuid for cftoken set on the server so my
so it was looking like
CFID=7307&CFTOKEN=E81A40DA
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.
afaik, cf uses the cookie (either jsessionid or cfid/cftoken combination) to track sessions on the server
ie:
JSESSIONID=f03010e3214b683
or
CFID=7307&CFTOKEN=17386890
and this is the only thing that gets passed back and forth as the identifier
I can see how
CFID=7307&CFTOKEN=17386890
could be easily predictable, however I do have use uuid for cftoken set on the server so my
so it was looking like
CFID=7307&CFTOKEN=E81A40DA
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.
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
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
ASKER
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.
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.
ASKER
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.
http://www.owasp.org/index.php/Configuration
( 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...
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.
http://www.owasp.org/index.php/Configuration
( 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).
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
sorry that i'm uneducated in this matter
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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...
Name JSESSIONID
Value f03010e3214b683b398057647a
Host www.mysite.com
Path /
Secure No
Expires At End Of Session <<<<<<<<<<< Browser Cookie ?
Name JSESSIONID
Value f03010e3214b683b398057647a
Host www.mysite.com
Path /
Secure No
Expires At End Of Session <<<<<<<<<<< Browser Cookie ?
ASKER
you could be right...since FF3 uses sqllite for cookie mgmt now, I can't actually viewing a physical cookie location...
ASKER
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
thx to both
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 ...