Session fixation with CFML sessions

Description

It is possible to control what CFML session tokens a user will have by sending them to a link that contains a CFID of your choosing, so long as it fits the UUID pattern.

This means I can send a user to a URL, wait for them to login and then visit that URL myself in order to be logged in as that user (better description here: https://www.petefreitag.com/item/815.cfm)

What I believe to be happening is:

1. Original request comes in with CFID=myhackedvalue
2. no session exists with that CFID
3. Lucee creates a new session using the passed CFID

Instead of 3. I believe that Lucee should be generating a new CFID so that attackers cannot simply define a session with a CFID of their choosing.

Using j2ee sessions does not suffer from this problem.

Workaround 1

One workaround is to use SessionRotate() in OnSessionStart() in your Application.cfc:

component { //... function onSessionStart() { SessionRotate(); } }

That's pretty brutal, but will ensure that you can never dictate the session tokens that are used for your session.

Workaround 1a

There's a small issue with the workaround above, the CFID and CFTOKEN cookies will be set twice, once with the original tokens (which may be passed in the URL), and again with the new ones. The following will get around that but might not be quite so comfortable:

component { //... function onSessionStart() { _removeSessionCookies(); SessionRotate(); } // ... private void function _removeSessionCookies() { var pc = getPageContext(); var resp = pc.getResponse(); var allCookies = resp.getHeaders( "Set-Cookie" ); var cleanedCookies = []; for( var i=1; i <= ArrayLen( allCookies ); i++ ) { var cooky = allCookies[ i ]; if ( !ReFindNoCase( "^(CFID|CFTOKEN|JSESSIONID|SESSIONID)=", cooky ) ) { cleanedCookies.append( cooky ); } } pc.setHeader( "Set-Cookie", "" ); for( var cooky in cleanedCookies ) { resp.addHeader( "Set-Cookie", cooky ); } } }

Environment

None

Activity

Tim Smolders 
23 April 2021 at 14:06
(edited)

thanks Brad, if I thought I had found a bug, I would have!

If we detect url/form CFID, we log the user out immediately.
Thread safety in this app needs a hard look. Thanks!

Brad Wood 
23 April 2021 at 14:03

If you believe you've found a bug, please create a new ticket. Don't comment on a tivket closed 5 years ago. As far as the behavior you noticed, I would check and see if you have "addToken" turned off of your cflocation tags. If your app is generating URLs that contain the CFID in them, then all it takes is a user copying the URL they have in their browser and sending it to another user and they can get the original person's session. It's also worth noting that one user seeing another user's session data can also be caused by poor thread safety in your application code. Such as singletons not using locally var'd variables.

Tim Smolders 
23 April 2021 at 12:43

5.3.7.47. Sorry, no demo as we cannot reproduce. I give up.

Code above only seems to clear OTHER cookies than CFID etc. (regex does not match CFID etc, because of !).

But even if it worked and CFID would be set, it would be set empty ..
Resuming trial and error 🙂

Never mind my ramblings & good day.

Zac Spitzer 
23 April 2021 at 12:03

which version of Lucee, have you got a demo?

Tim Smolders 
23 April 2021 at 10:33

We encoutered an issue where a user was suddenly logged in as another user, and we suspect “getPageContext” to have shared users A’s cookie with user B.
Is it (thread) safe enough to use?

The only other reasons this happened (that I can think of) is that a newly logging in user received the exact same CFID that was given to another user hours before. (one in a billion chance?)

Fixed

Details

Assignee

Reporter

Priority

Fix versions

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Created 17 February 2016 at 12:29
Updated 27 April 2021 at 09:45
Resolved 21 November 2016 at 22:37