JSESSIONID changing on every click, refresh, form submit, etc.

[WolfShade]

Hello, all,

My boss is working on an addition to our site that has a form to submit that a user can use to submit a complaint.  He is using a custom-made CAPTCHA that is randomly generating a three digit number and setting that to a session variable.  The form handler page then compares what the user entered to the session variable.  But the JSESSIONID is changing on every click, etc., so when the handler gets the form, it's a new session and the values do not match.

What can we do to make this work?

V/r,

^ _ ^

[BKBK]

WolfShade  wrote

But the JSESSIONID is changing on every click,

Do you mean, on every click on the submit button?

[WolfShade]

I mean EVERYTHING.  With F12 on FireFox, showing the cookies, every link click, form submit, page refresh/reload, even if you manually change the URL to another page.  JSESSIONID rotates.  Apparently as a security measure against session hijacking.

But how do I keep session variables persistent if the JSESSIONID is forever changing?

V/r,

^ _ ^

[haxtbh]

Are you actually losing the full session scope on the page refresh? Coldfusion should be dealing with this for you.

If you assign something to session.testvar and then output it to the page, keep refreshing. If it exists on each refresh then its keeping the session fine.

You haven't got any low timeouts set to the session?

[WolfShade]

For testing/debugging, when the form page loads, session.captcha is set to a random number and a javascript alert will show what the session.captcha is.  When the form submits to the handler (straight form submit, not AJaX, or anything), a javascript alert displays #session.captcha#, which (if not paramed on that page) results in "session.captcha does not exist" message.

F12 shows JSESSIONID is different on every page load, refresh, link click, etc.  Everything.

V/r,

^ _ ^

UPDATE:  CFLOCATION is not being used.

[BKBK]

I think we have to go back to basics on this one. The observed behaviour implies that ColdFusion starts a new session at every request.

What's the ColdFusion version? Is Application.cfc or Application.cfm in use? What are its this-scope settings?

[BKBK]

WolfShade  wrote

  JSESSIONID rotates.  Apparently as a security measure against session hijacking.

The new session functions, sessionRotate() and sessionInvalidate(), don't apply to J2EE sessions, only to ColdFusion sessions.

But how do I keep session variables persistent if the JSESSIONID is forever changing?

Let's suppose you're using Application.cfc and reasonable values for the this-scoped variables, for example, applicationtimeout of 1 day and sessiontimeout of 20 minutes. Then my guess is that something is resetting the session in onRequestStart.

[WolfShade]

Hi, BKBK,

Here are the this-scoped vars:

    <cfset this.applicationTimeout = createTimeSpan(0,6,0,0) />
    <cfset this.sessionTimeout = createTimeSpan(0,0,20,0) />
    <cfset this.scriptProtect = 'all' />
    <cfset this.sessionManagement = 'Yes' />
    <cfset this.setClientCookies = 'Yes' />
    <cfset this.clientManagement = 'Yes' />
    <cfset this.sessioncookie.httponly = 'Yes' />
    <cfset this.setdomaincookies = true />

CF11, application.cfc (we moved away from application.cfm a long time ago).

I'll look in onRequestStart() to see, but I don't think there's anything there that could do this.

V/r,

^ _ ^

[BKBK]

Looks good. One more:

<cfset this.name = "myApplication">

[WolfShade]

  Application is named, I just didn't include that.  Standard USG DoD paranoia. 

V/r,

^ _ ^

PS..  I didn't find anything in onReuqestStart() that could be causing this.

[BKBK]

I would perform the following checks:

1) Ensure that the following settings are checked (in the ColdFusion Administrator):

Use J2EE session variables

Enable Application Variables    

Enable Session Variables

2) Search your code to rule out the presence of the following lines of code:
structClear(session)
getPageContext().getSession().invalidate()

[WolfShade]

1) Ensure that the following settings are checked (in the ColdFusion Administrator):

Use J2EE session variables                CHECK

Enable Application Variables               CHECK

Enable Session Variables                    CHECK

2) Search your code to rule out the presence of the following lines of code:
structClear(session)                                        NOT PRESENT
getPageContext().getSession().invalidate()     NOT PRESENT

V/r,

^ _ ^

[BKBK]

Promising!

[BKBK]

I would do the following test:

1) Place this line of code at the beginning of onSessionStart:

<cfdump var="#session#" label="In onSessionStart">

Place this line of code at the beginning of onRequestStart:

<cfdump var="#session#" label="In onRequestStart">

Place this line of code at the beginning of onSessionEnd:

<cfdump var="#session#" label="In onSessionEnd">

2) Create these 3 CFM pages in the same directory,

testpage1.cfm

<a href="testpage2.cfm">test page 2</a>

testpage2.cfm

<a href="testpage3.cfm">test page 3</a>

testpage3.cfm

<a href="testpage1.cfm">test page 1</a>

3) Open testpage1.cfm in the browser. What is the output? (Printscreen. Blank out any sensitive information from the image)

Click on the link to testpage2.cfm. What is the output? (Printscreen)

Click on the link to testpage3.cfm. What is the output? (Printscreen)

Click on the link to testpage1.cfm. What is the output? (Printscreen)

[WolfShade]

V/r,

^ _ ^

[BKBK]

Weird. The images suggest that the browser has stored the same CFID and CFToken cookies across requests, implying a single session. But the JsessionID cookie changed at every request. This suggests that a new session starts at every request, implying that the JsessionID cookie is not being saved in the browser.

A quick search on the web brings me to this page on "JSESSIONID cookie is not stored in browser". Does this say anything to you?

[WolfShade]

Thank you for that link.  I have passed it on to my boss and our SA for consideration.  Boss seems to think it's plausible.

But, it's a Friday, and we never do anything huge on a Friday!  So since Monday is a federal holiday, we'll be running some tests on Tuesday, to see if that might be the problem.  It's a start!  Thank you, again.

V/r,

^ _ ^