Hi, I recently upgraded my server to 6.2.1.122 and some very alarming things started happening.
I am getting constant reports of users being logged in as one user, and then loading the next page of my application as they browse and are suddenly logged in as someone else.
This never happened before 6.2.1.122 and no code change to my authentication has been made recently.
Its extremely alarming and it looks like its a session leakage bug of some sort.
I am reverting back to what I was on before and will report back if the bug does or does not go away.
I’ve reverted back to 6.2.0.321 and for the past 12 hours no reports of session leakage.
Is nobody else concerned this is a catastrophic bug for 6.2.1.122.
I wish I could provide a proof of concept but this was a real ghost in the machine situation I could not duplicate reliably. Just got reports from customers complaining about being logged in as other users unintentionally as they browse the website.
I am not able to provide a proof of concept. It was happening at random in prod and it would be very time consuming for me to create a test environment that I could use to try and reproduce it.
However, this was very real and it went away when I reverted back to 6.2.0.321.
Now I am scared to upgrade to future releases until we can figure this out.
One thing I should note is this is a legacy application using application.cfm rather than application.cfc.
Not sure if that would matter.
Let me know if you guys think of any other configuration information that would be helpful.
I’ve now had reports of this happening on Lucee 6.2.0.321 so reverting did not actually fix my issue.
I’m combing the code for possible bugs with the authentication system.
The way this app works, it stores the session.username and session.pwhash in the session variables and the authenticator code block checks these against the database for every page request of pages that need authentication. Sets session.userid if authentication is successful.
I have now switched it to only checking against the database if the session.userid value is not set. So, lets see if it makes an impact. I’m trying just about anything to make this go away. So i’m thinking it has something to do with checking against the database. LIke maybe its a database caching issue.
One of the user’s of the system noted that when it happened to her she was always clicking the link to the “Portal” from the company public website.
I inspected the link, and it seems when they gave the link to the portal to the person doing the company site, they included a CFID= parameter.
And so whenever someone associated with the company used the link from the site , it would log them in as someone else.
I could never reproduce it on my end because I would never link from the main website. I just have the link to the portal bookmarked with no CFID.
As soon as I went to the main website and clicked the link I was logged in as someone else. It seemed to reliably log me in as the last person who logged in.
That is an extremely odd coincidence I think, and points to a flaw in how Lucee is generating CFIDs.
Because, the hard-coded CFID in the link on the website. Was reliably logging people in to the last person who was logged in before them. How could this happen? Those IDs are supposed to be very random.
According to this finding, we can enable CFID URL Params in an app, then log in to that app, and snatch a CFID, and save it. Then re-use it over and over and get logged in as other people.
This part doesn’t make sense and I’m hoping someone can test this proof of concept.
I think i just figured out why it reliably logs you in as the last person… Its because if the CFID doesn’t exist, it gets created as that CFID. Then that person is logged in with that CFID. Then the next person comes along, and clicks the link from the main website, and gets that CFID’s session. Causing them to be logged in as the last person who logged in from the link from the main site.
Since all customers and staff use that link, this turned into a security mess real fast.
Need to disable CFID’s in URL I suppose for this app.
This feels like you are doing session management via URLs instead of cookies – which hasn’t been recommended in years for precisely the reason you found.
You should check to make sure in your application.cfc that you have the application.sessionManagement set to true, and that you aren’t overwriting the application.setClientCookies or application.sessionStorage variables. It would be a good idea to make sure you aren’t manually providing the CFID/CFTOKEN in the URL and you are using the addToken=false in any cflocation tags.
This is exactly why you should never use session identifiers in any URL. Its very likely to be exposed to session fixation. Just imagine a logged user sharing a link with those identifiers to social media or messaging applications… it will just repost a link to his account. Using those in URL variables is very old ( formerly unknown bad) practice in web apps history. That is why the Lucee team decided to finally make some breaking changes to this old default behaviour in cfml (see Lucee 6, changing some old defaults to be secure by default)
Wow yes I realize the mistake in my ways by allowing these CFID’s in the URL.
Now the problem hasn’t completely gone away so it gets interesting still, where as I have the bad URL with the CFID in the url removed from the link from the main website. However, all the customers of this site have at some point clicked that link and have the cookie of that session saved. So they are still logging in to one another’s sessions.
I need to tell everyone who ever clicked that link to clear their cookies I think.
Because the problem I have now is that this issue still exists since it seems cookies with the same session id exist among the users of the site.
How, do I revoke all sessions from the web server? Or prevent a particular CFID from existing or ban it somehow. So anyone using that CFID has to re-login or somehow re-assigned a new one?