PCI Compliance: Non-Secure Session Cookies Identified

dev support
1

CentOS Linux 8.4.2105
Linux 4.18.0-305.3.1.el8.x86_64 on x86_64
Java 11.0.7 (AdoptOpenJDK) 64bit
Apache Tomcat/9.0.35
Lucee 5.3.7.48

Hi there. We are getting the message “Non-Secure Session Cookies Identified” returned from our PCI Compliance scan.

Appplication.cfm contains

cfset cf_ssn_cookies = {httponly=‘true’, secure=‘true’}

CFAPPLICATION NAME=“DEVMAR202008” CLIENTMANAGEMENT=“Yes” SETCLIENTCOOKIES=“Yes” CLIENTSTORAGE= “cf_client_vars_lucee_5_1_m” sessionmanagement=“yes” clientCluster=“true” setdomaincookies=“Yes” sessioncookie=“#cf_ssn_cookies#” sessiontimeout=“#createtimespan(0,0,30,0)#”

Based on our research, we would expect the sessioncookie setting above to make both CFID and CFTOKEN cookies both Secure. When I inspect them with Chrome Dev Tools - they are httponly = yes, but the Secure flag is NOT set…

What am I missing? Any ideas? Thanks so much!

3

What you have should work, it is what I have and it works for me. I assume you are accessing it over HTTPS? Obviously you can’t set a secure cookie over HTTP, e.g. if you testing in a dev environment where you are not using HTTPS or something.

4

Thanks. Great point. Thanks so much for your response.

I do see the secure flag sometimes for my personal session. However, we are failing the PCI scan consistently. And when I use an incognito window (with https), the secure flag is missing.

I know that Application.cfm is not recommended (we need to migrate to .CFC

I guess I wanted to verify that this config works with application.cfm? And figure out what else we are missing.

5

What I did, just to be sure that secure flags are always beeing set, I’ve added the secure flags on web server level.

6

Interesting. Thanks so much for your response.

“I’ve added the secure flags on web server level”

I don’t think I know what this means.

Would you mind sharing with me how you did that?

7

On Apache you can do:

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

using mod_header to “edit” the cookie before it is sent back to add it.

8

I’m not at home right now to check. It depends on which web server you are using. If Apache, look at this post from stackoverflow

You just need to be carefull to not set the attributes twice, because this would not be compliant, and some browser wouldn’t work properly.

9

I’ve just checked an older application I have using and it has:

<cfset sessionCookie = { httpOnly=true, secure=true }>
<cfapplication ...
					sessionCookie="#sessionCookie#">

Which is the same as what you have and I’ve just tested this and it is working fine. Maybe your web server is editing the cookie and removing them for some reason. What are you using for a web server?

1 Like
10

Great question. You guys are so helpful!

Apache/2.4.37 (centos)
Apache Tomcat/9.0.35

11

Thanks so much. I read through the stackoverflow article you suggested and found other stuff related to this for Apache.

This article was quick and to-the-point, suggesting a single edit to the httpd.conf file:

https://geekflare.com/httponly-secure-cookie-apache/

I added this line below to httpd.conf, then restarted httpd service:

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Now I am seeing the Secure flag for both CFID and CFTOKEN. I also ran an online testing tool which showed both HTTPONLY and SECURE (before - was only showing HTTPONLY, but missing secure flag).

Thanks so much everyone. This was a huge help! :slight_smile:

1 Like
12

As I’ve said before, verify and make sure the flags are not being set twice anywhere. We had that and I remember it breaking cookiie handling in Firefox.

13

I’m with Andreas, in suspecting there’s other code that could be overriding your app-level setting there. (The apache tweak, while it’s FORCING secure for any cookie, should not be needed and may even prove to be trouble for other reasons down the road.)

If you can easily modify the code, I’d be curious if you put a cfabort right after the cfapplication and tested again. Does it still not show the secure cookie being sent/set in your browser dev tools? (Remove the apache tweak and restart it first, of course.)

Or if you can’t mod the code, create a new folder with a blank application.cfm, copying into it that cfapplication (and any code setting vars in it). Then put a blank index.cfm and call it. What do you see? If you’ve removed the apache tweak and DO see the secure cookie headers being sent/set, then yes it was some other code in the “real” request/app that was overriding what this code was doing.

And it can be any of a number of things manipulating the cfid/cftoken, whether a cfcookie or a simple setting of cookie.cfid, etc. Those presume to apply defaults, so the default for them may be (and I’m pretty sure would be) secure=false, for ANY cookie set that way.

Let us know if this helps. Sorry for the lengthy reply, but sometimes these challenges do require more than a brief one. :slight_smile: Indeed, I could share more but let’s see if you’ve resolved things.

14

Thx. I saw your note and have been thinking about this potential conflict. Do you mean: I should not be setting the flag in both Apache conf AND application.cfm?

I took your note to mean that I need to ensure the secure setting is not in https.conf twice - which it is not. Where else would I need to worry about?

Either way, I tested this config in chrome, edge and Firefox- all Pass.

Also, the third party check is now passing (failing before).

1 Like
15

LOL - I think we were typing at the same time.

Great feedback guys. I greatly appreciate it. AND - I really need to get this right before moving to production and mucking up our SLAs.

YES - Full control over everything… I like your suggestion.

I put in the CFABORT directly under the cfapplication statement (after backing out my httpd.conf change and restarting)… It went back to a failure state (where the Secure flags are new missing when tested in an incognito window)…

Screenshot 2021-06-19 130519
Screenshot 2021-06-19 1305191726×265 53.4 KB

The external testing tool shows the same (Secure flag missing)

download - 2021-06-19T130947.802
download - 2021-06-19T130947.8021112×270 26.8 KB

What could possibly be doing this?

16

Check over all the apache configuration files to make sure there isn’t anything similar to the line you added, remember it might not be in httpd.conf, it might be in a include, that is editing the cookie, so maybe do a grep for Header edit and see if there is already something else there editing the cookie. Either that or in the Tomcat configuration, but I don’t know what that would be.

17

From a quick Google, it looks like in Tomcat it would be a CookieProcessor element.

18

Another way to find out if it’s something ELSE in Apache messing with things (as Andrew notes) would be to test your requests against CFML code running via the built-in (Tomcat) web server rather than via Apache. Have you tried that yet, again even with just some simple test code as we’ve been discussing?

Depending on how you installed Lucee, you may have a Lucee webapps/ROOT folder where you can drop in such test code, and then browser it via 8888. But there are so many different ways that people can install and configure Lucee, so if you have access to the Lucee Admin, on its overview page, the bottom section on “web contexts” will tell you both values.

If code tested that way still failed to show the use of secure cookies (for CFID/CFTOKEN), then we know the issue is either in Lucee or in Tomcat (as Andrew also proposed might be possible). Each step gets us closer to knowing the cause–and therefore a potential solution. :slight_smile:

19

Thanks guys. I will test tomcat next.

Something I failed to mention in our config, that I realize may be extremely relevant, is that all SSL processing is off-loaded to the AWS load balancer - which is upstream (obviously) from the prod web server cluster. So, as far as tomcat / Apache / Luce are concerned - everything runs on port 80 / http. Is this part of the puzzle?

20

I don’t think that matters as that is the configuration I’m using and it hasn’t affected it and I don’t think AWS ELB has any options to change the cookie headers but always worth double checking.

21

Okay. Thanks.

Based on your suggestion above, I dug into the Tomcat config settings. I found this helpful article:

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

Unfortunately, it did not work. Still missing Secure Flag for CFID and CFTOKEN… Which seems to point to something in my Apache config as the problem (and so far, the only place I’ve round a solution).

I’m not sure how to do that because (as discussed) the entire environment is non-ssl / http. I did put in the cfabort in application.cfm - but since I can’t load :8888 securely, I think this is a false positive. Right?

Also - Dumb question at this point perhaps - but are you guys using Session Type = Application? (we are).