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.
I currently have enabled
Use J2EE session variables
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?
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
EDIT: The scan occurred before I made the client variable
changes to the applicaiton.cfm (so I had both jsessionid and
cfid/cftoken being set) As of now only jsessionid is being set
"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.
It looks like the J2EE sessions are the way to go.
I believe the reason for the PCI flag is that the scan (at
least the one from the service we use) was looking at CFID alone. I
assume this because cftoken -was- set to use uuid so it should have
been secure. The scan probably doesn't know that cfid and cftoken
are used in conjunction. So in a way this is a false positive.
Based on the new standards coming in it is enough to be out of
solution to be in compliance is to set clientmanagement="no"
and setclientcookies="no" in application.cfm so that cfid and
cftoken are not set at all By using only the jsessionid, you are
following best practices from OWASP and also get the benefits of
session end on browser close