CFGLOBALS cookies not secure

dev support
1

Security scans report as a security risk that CFGLOBALS cookies are not marked as secure. We have been unable to find a way to fix this.

From the Acunetix security scan results:

Identified Cookie(s) CFGLOBALS
Cookie Source HTTP Header
Retestable
Vulnerability Details
Acunetix 360 identified a cookie not marked as secure, and transmitted over HTTPS.

This means the cookie could potentially be stolen by an attacker who can successfully intercept and decrypt the traffic, or following a successful man-in-the-middle attack.

Impact
This cookie will be transmitted over a HTTP connection, therefore if this cookie is important (such as a session cookie), an attacker might intercept it and hijack a victim’s session. If the attacker can carry out a man-in-the-middle attack, he/she can force the victim to make an HTTP request to steal the cookie.

System Information
Version Lucee 5.3.8.201
Version Name Gelert
Release date Aug 6, 2021
Remote IP fe80:0:0:0:f910:5c7e:a8d2:f261%23
Servlet Container Apache Tomcat/9.0.41
Java 15.0.1 (Oracle Corporation) 64bit
Windows 64 bit (also happens on Linux)

2

Doest that cookie even exist on Lucee? Isn’t CFGlobal an Adobe specific cookie? I’m not sure, because I’m not a Lucee developer, but a quick search in the Lucee code didn’t get a single hit, just can find this here and cfglobals isn’t mentioned at all:

However, you may be able to set cookie flags similar to how Peter Freitag did it with sameSite flag using the fronted web server IIS (see here).

1 Like
3

The cookie does exist:

image

4

Ok… So… If they do exist and you are totally sure this is running on a Lucee engine, please verify if your app is creating them somewhere. A strong sign that these are being created manually by your web application (e.g. by the use of cfcookie tag) is, that your cookies names are upper case. As far as I remember, Lucees inbuilt cookie creation feature creates cftoken and cfid by default in lower case. So please check/search your web application for cfcookie tags that are creating/overwriting cookies somewhere.

5

Its an application, it literally only does exactly what tell it and or configure it to do.

Your configuration needs be corrected if you do not want your cookies insecure.

A web application is a stateless and neither the browser nor the application care how you deliver content unless you tell it otherwise

Here are some suggested corrections

  • Use a third party SSL firewall / load balancer and only accept SSL based traffic
  • Configure your Application to only use SSL (Block Internal and external port 80 requests
  • Code your application to use webroot = https://yourapplication
  • Code your cfCookie Scope / path check and header to use Webroot above
  • Remove any third party Web servers such as IIS, Apache (HTTPD) or other and configure Tomcat to directly serve a CA based certificate
  • Further optimizations
  • ****Code your application in CF for only CF based components on Tomcat
  • ****All other assets on a separate server(s) for better performance
6

cfglobals is created automatically by cf. I’ve searched the app to see if there is anything in it creating that cookie and there is not.

I’ve tried adding this.sessioncookie.secure = true; to the application file and it doesn’t affect it.

The app is loading as https://

I’ll discuss the other suggestions with our team.

7

Under Settings - Scope
You have your client cookie settings for the scope

then with CFAPPLICATION, you can set ClientCookies and domainCookies
I would create a dummy page and debug with

<cfloop
list="application,session,variables,client,url,form,request,server,cgi"
index="i">
<cfdump var=#evaluate(i)# label="#i#">
</cfloop>
1 Like
8

Terry, I’m not quite sure what you mean.

I did find code that was creating the cfglobal cookie by setting it to expire but the real issue is the lack of http and security for all CF specific cookies (CFID, CFTOKEN).

I added
this.sessioncookie.httponly = true;
this.sessioncookie.secure = true;
to the application.cfc but that didn’t fix the issue.

I also confirmed that the site is being served over ssl.

image

9

You can force transport of your “cookie” via SSL either via hardware or via configuration.

You could set CfCookie to NONE in scope, and in your cfapplication

Cookies are inherently insecure.

Better methodology is to use sessions.

10

These cookies are session cookies. I don’t set cfid and cftoken using cfcookie.

11

It’s working for me?

session/Application.cfc

component output="false" {

  this.name="test" ;
  this.sessionManagement = true ;
  this.setclientcookies = true ;

  this.sessioncookie = {
    'httpOnly'  = true,
    'Secure'  = true ,    
    timeout = 0,
    'sameSite' = "strict"
  } ;

  cfsetting( showdebugoutput="true") ;

}

session/index.cfm

<h1>hello world</h1>
<cfset session.hello=1>
<cfoutput>#server.lucee.version#</cfoutput>

C:\work\lucee\loader>curl -v http://127.0.0.1:8888/session/index.cfm

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> GET /session/index.cfm HTTP/1.1
> Host: 127.0.0.1:8888
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200
< Set-Cookie: cfid=c5f3c3c0-a71d-453e-980d-aa1f237208bb;Path=/;Expires=Mon, 25-Oct-2021 14:17:57 UTC;Secure;HttpOnly;SameSite=Strict
< Set-Cookie: cftoken=0;Path=/;Expires=Mon, 25-Oct-2021 14:17:57 UTC;Secure;HttpOnly;SameSite=Strict
< Content-Type: text/html;charset=UTF-8
< Content-Length: 24
< Date: Tue, 05 Oct 2021 12:39:53 GMT
<
<h1>hello world</h1>
5.3.8.205-SNAPSHOT* Connection #0 to host 127.0.0.1 left intact

When debugging this, the only source of truth is seeing a Set-Cookie header being sent. Curl is a great way to test this as it always creates a new session

2 Likes
12

We get around this by making client and session storage memory, file or database, depending on the application.

13

Still, the cookie names you showed us in your screenshot are all uppercase (CFTOKEN/CFID). Lucee by default creates cookies in lowercase cftoken/cfid (to understand this, please see this ticket I’ve issued). The uppercase usually comes when you are using cfcookie (without using the preservecase attribute). I’d bet your app has some code somewhere or something in the http chain (like firewall, proxy, router, web servers header module) is chainging the server response header.

@isruther By the way, what was creating your CFGLOBALS cookie? Would be interessting for others to know, for the case they have the same issue.

14

We had a tag.

I’m looking at the case issue now. Thanks everyone for your input so far.