JSESSIONID secure and httpOnly??

[WolfShade]

Hello, all,

We have been alerted to a minor finding.  JSESSIONID session cookies are not secure.  The CFID and CFTOKEN are secure and httpOnly.

We followed instructions from a 2014 thread to make JSESSIONID session cookies secure and httpOnly.

Viewing in FireFox with DevTools, initially the JSESSIONID cookies are secure and httpOnly, but if you click on to another cookie, then come back to JSESSIONID, the cookie is NOT secure.

Viewing in IE11 with DevTools, the JSESSIONID cookie shows twice; once as secure and httpOnly, once as not secure but httpOnly.

What is happening??  I'm at a loss, on this one.

V/r,

^ _ ^

[Dave Watts]

If your initial connection is not secure, and gets redirected, I think you might end up with two copies of it. Do those copies have identical values?

What version of CF are you using?

I'd look at implementing the fixes shown here:

https://geekflare.com/secure-cookie-flag-in-tomcat/

Dave Watts, Eidolon LLC

[WolfShade]

DISA STIG dictates that redirecting from http to https is a security vulnerability, so we no longer redirect :80 to :443.

Yes, the two cookies have identical values.  We are currently using CF11, I'm sure we have the latest updates.  As soon as a CF update is available, it is thoroughly scrutinized then applied as quickly as possible.

Thank you for that link.  I have passed it on to our DBA and our SA for review.

V/r,

^ _ ^

[pete_freitag]

FYI Tomcat will set the JSESSIONID cookie as secure as long as it thinks the request is made over https. Not sure why you are getting two cookies, most often this is due to having some code that is trying to set a cookie manually.  I did some looking into this a few years ago: https://www.petefreitag.com/item/817.cfm

[WolfShade]

pete_freitag  wrote

FYI Tomcat will set the JSESSIONID cookie as secure as long as it thinks the request is made over https.

I had read that, somewhere, and for whatever reason it isn't working out that way.  It would not surprise me if something in our network security stance has something to do with it.

And we don't have any code trying to set a cookie that CF is already setting.  And why twice in IE, but not in FF?  Frustrating.

V/r,

^ _ ^

[pete_freitag]

If you had a proxy or load balancer that is doing SSL termination, and then proxying over plain http then Tomcat would not realize it should be setting a secure cookie. But I'd think in your case you would probably not be doing that. Either way best bet is probably to make sure you have setup tomcat to always set the secure flag for jsessionid, eg like this

<cookie-config><http-only>true</http-only><secure>true</secure></cookie-config>

in web.xml

Probably not related but I was reminded of this when you mentioned IE working differently with cookies : https://www.petefreitag.com/item/857.cfm

[WolfShade]

Our DBA did follow those instructions, and it's still happening.

I think (don't know for sure) that we are using proxy and load-balancers, but nothing is http, it's ALL been pushed to https.  That was a USG-wide directive, some months ago.

V/r,

^ _ ^

[Dave Watts]

It's pretty common to have a load balancer listening on HTTPS, but talking to its servers via HTTP. This makes certificate management a lot easier. I don't know if that's how your environment is set up, though. It's reasonably secure as long as you control traffic on the load balancer's network.

Dave Watts, Eidolon LLC

[WolfShade]

I passed that along to DBA and SA, and apparently everything is communicating via httpS, nothing http.

V/r,

^ _ ^

[Dave Watts]

This can potentially introduce a wrinkle, I guess, as your load balancer can rewrite cookies and create its own. I have no idea why your load balancer would be doing that, especially only for IE, but it's a possibility I guess. Personally, I prefer using plaintext HTTP between the load balancer and the individual sites, if for no other reason than certificate management becomes a lot easier, but I understand your environment might not allow that.

Dave Watts, Eidolon LLC

[WolfShade]

https://forums.adobe.com/people/Dave+Watts  wrote

... but I understand your environment might not allow that.

USG is (understandably) paranoid about network security, desktop security, you name it.  Imagine the most secure network that you have personally worked on, multiply it by 10, and you'll start to get an idea of how tight security is around here. 

V/r,

^ _ ^

[BKBK]

WolfShade  wrote

Hello, all,

We have been alerted to a minor finding.  JSESSIONID session cookies are not secure.  The CFID and CFTOKEN are secure and httpOnly.

We followed instructions from a 2014 thread to make JSESSIONID session cookies secure and httpOnly.

It would help to know which instructions you followed. They might need reviewing.

[WolfShade]

The link provided by Dave Watts, https://geekflare.com/secure-cookie-flag-in-tomcat/.  Those instructions were followed, and it's still acting wonky.

V/r,

^ _ ^

[BKBK]

I wish to add a third voice, confirming the suggestions you've received from Dave Watts and Pete_Freitag

The setting to use is

<session-config>

     <session-timeout>30</session-timeout>

     <cookie-config>

          <http-only>true</http-only>

          <secure>true</secure>

      </cookie-config>

</session-config>

or, equivalent, in /runtime/conf/web.xml of every instance.

[WolfShade]

I have just been assured that the code you provided is, indeed, in place.  Yet we are still experiencing what I described, above.

V/r,

^ _ ^

[Dave Watts]

Are there any settings on the load balancer which might be duplicating cookies for some reason? I can't imagine why that would be happening, but you could test that by connecting directly to one of the individual servers behind the load balancer and seeing what happens.

Dave Watts, Eidolon LLC

[WolfShade]

One of my colleagues is attempting to recreate an issue in FF.  Meanwhile..

I have navigated directly to one of the servers in the load-balancer setup.

I have two images that I'll upload, here.  The first is what we see in IE11:

Now, what I see in FireFox:

Notice that this says it's NOT secure.  It was saying secure, earlier.  Then you could click a different cookie, come back to JSESSIONID and it would say not secure.  I don't know why it's not co-operating, today.

V/r,

^ _ ^

[WolfShade]

Here is what my co-worker is seeing (I'm not able to recreate on my system.)

Image on right is first, showing encrypted connection only; image on left is after he clicked to a different cookie, then came back to JSESSIONID.

V/r,

^ _ ^

[Dave Watts]

Are you using CFLOCATION to redirect from HTTP to HTTPS? If so, that may be passing the JSESSIONID in the URL, which may add some complications here. Try adding this to your <session-config>...</session-config> block:

<tracking-mode>COOKIE</tracking-mode>

Note: this is only a wild guess. Good luck!

Dave Watts, Eidolon LLC

[WolfShade]

DISA has determined that forwarding is a security issue and we are instructed (task order) to not redirect from http to https.

However, I just learned that another task order has instructed the domain to forward from http to https.  So, while our web servers do not have any config for a redirect, and we do not have any code in place for a redirect (no cflocation or anything else), the domain does redirect (not sure how, but it does.)

I'll pass your suggestion on to our SA and DBA and see what they say.  Thanks!

V/r,

^ _ ^

[WolfShade]

He added that to the web.xml file, and it's not making any difference.

V/r,

^ _ ^

[BKBK]

WolfShade  wrote

I have just been assured that the code you provided is, indeed, in place.

For every single ColdFusion instance?

That was one point.

A second point, perhaps related to the first, has been alluded to by Dave Watts. Your application has actually created a second JsessionId. It did so by replacing the dot (.) by its URL encoding, %2E. This suggests that your application is passing a new, URL-encoded JsessionId cookie.

[WolfShade]

We have only one instance, one web.xml.

As far as the second JSESSIONID, I didn't even look to match the values or see that one was encoded.  I'll see if I can figure that one out.  Thanks!

V/r,

^ _ ^

[WolfShade]

DBA asks me to look at our code to see if anything is out of whack.  SOMEONE (I don't know who, we are not using a repo) placed a CFCOOKIE in the onSessionStart() called (drum roll, please) JSESSIONID.  I commented it out and sent it to be synced.  See what happens.

V/r,

^ _ ^