Yes, are set...
I can not say exactly why remains the CFID CFTOKEN and the cookie but I know that even with them there you can only capture and enjoy a session, including the session traker API, via jsessionid. Have made myself this question and the only conclusion I reached was that the CF should create linkages within the internal structure linking it somehow to the jsessionid but as the tract of a session CFID CFTOKEN and has no influence on the session available to the user.
Thanks to both Eduardo and BKBK for the replies.
As Eduardo mentioned, when using J2EE session management, CFID and CFTOKEN do not appear to be connected to the session. By creating a session in one browser and manipulating the cookies in a 2nd browser, I was able to steal the session using jsessionid but not with CFID and CFTOKEN.
The CFID and CFTOKEN cookies are flagged by security auditing software as a vulnerability because they are persistent, not session, cookies. Is there any way to force CF to set CFID and CFTOKEN as session cookies instead?
The CFID and CFTOKEN cookies are flagged by security auditing software as a vulnerability because they are persistent, not session, cookies.
The auditing software must be giving you a false positive. In my opinion, CFID and CFTOKEN cookies are non-persistent, and cannot outlast the session in which they are created.
There are ways to force the CF create cookies SESSION simply change the cfcookie to be a session cookie and tag you find these two links:
I agree with his statement and is so even though the documentation says.
When I followed Ben Nadel's post on forcing the CFID and CFTOKEN as session cookies, I found that those cookies are not set at all if the the application's SetClientCookies property is set to a false value:
<cfset THIS.SetClientCookies = "No">
As the docs (well, the CF8 docs that Google found) point out, the default value for SetClientCookies is true, so that's why I was getting CFID and CFTOKEN.
Thanks for pointing me in the right direction!