CODEWITHSUNDEEP
coldfusion
Matt Dyer
Matt Dyer

Reputation: 126

JSessionID cookie being set with J2EE session variables option unchecked

I am running Coldfusion 10 Update 14 (10,0,14,291717).

Is it normal for the jsessionid cookie to be set when the "Use J2EE session variables" option is unchecked in the cfadmin.

It is being set in the response from a page that is posted to using a form with enctype set to multipart/form-data. It seems to happen with any form in our application if I change the enctype. That is the only time I see it being set. There could be other conditions that cause it to be set, but I haven't found any. It doesn't happen if the form has no enctype set. It also doesn't happen for get requests.

Should this cookie ever be set if the option is unchecked in the cfadmin?

Is it normal for it to only be set with this particular type of post request?

This happens on my development machine Mac OSX 10.9.5 and on our production server running Windows Server and IIS.

These are the response headers from the page that sets the cookie. The page does some form processing and then does a cflocation.

HTTP/1.1 302 Found
Date: Wed, 10 Dec 2014 20:42:21 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_jk/1.2.32 mod_ssl/2.2.26 OpenSSL/0.9.8za
Set-Cookie: JSESSIONID=A61590143D1AD60644B208F25990F8FA.cfusion; Path=/; HttpOnly
Location: http://localhost/ethm/maintenanceForm/mrformv7/main.cfm?pid=home&BID=1995
Cache-Control: no-cache
Pragma: no-cache
Keep-Alive: timeout=5, max=49
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8

More Information:

I updated my development cf to update 15 so the version is now 10,0,15,292620.

I created a new folder in my local site and put the following 2 files in the folder:

Application.cfc

component{
}

index.cfm

<form enctype="multipart/form-data" method="post" action="index.cfm">
<input type="submit" value="Go">
</form>

Then if I clear my cookies and go to that page I get no new cookies. If I submit the form I get a JSessionID cookie. I can clear it and I get a new one every time I submit the form. If I don't clear my cookies the same one stays.

Upvotes: 0

Views: 1662

Answers (2)

WilGeno
WilGeno

Reputation: 185

I just searched through the Adobe ColdFusion bug base and found this bug report https://bugbase.adobe.com/index.cfm?event=bug&id=3430245

This is related to what we are seeing (if not the exact same thing) and it was "fixed" in CF10u14 and CF11u3.

However, I can verify the results you're getting, as Mark already posted, in CF10. So after I found the bug report I went and tested this in CF11u3 and found that with J2EE Session variables turned off CF11u3 always sets the jsessionid cookie.

I created a new bug report with my findings and linked to the old bug report and this forum page. However, I made the mistake of tagging it as a 'security bug' because session cookies not being properly set is technically a security issue and now it's not visible to anyone including me. That will teach me.

Regards,

Wil Genovese

Sr. Web Application Developer/ Systems Administrator

CF Webtools

Upvotes: 0

Mark A Kruger
Mark A Kruger

Reputation: 7193

We tested this for you Mat (Wil Genovese) on CF10 UPdate 15. According to Wil CF does not set J2EE session cookeies if they are disabled in the CF Admin. However if an existing j2ee session cookie exists from when they were anabled it will persist until it expires. Hopefully that helps a little.

FYI - this was not on OSX.

EDIT: More information

Further testing revealed the following Matt.

When you issue a POST using multipart/form-data this condition (a J2EE cookie set) will always occur. If you change your POST header to /application/x-www-form-urlencoded it will not be set. And a GET request will not allow it to be set.

Using this Application.cfc (adding or subtracting settings and names):

component
{
 THIS.name = "je22test";
 THIS.Sessionmanagement = true;
 THIS.ApplicationTimeout = CreateTimeSpan(1,0,0,0);
 THIS.SessionTimeout = createtimespan(0,0,20,0);
 THIS.SetClientCookies = false;

}

...does not appear to have any effect. We are going to log it as a bug. I'm not sure the impact exactly. It might red flag a security scan - but you really should use rotating J2EE sessions anyway. Still, a scan might notice that it only rotates on a POST request. It would see it, then flag it (as an info warning probably) for not rotating. Not sure that's enough of a bug to fix or worry about, but lets see what Adobe says eh?

Upvotes: 1

Related Questions