Disable __cfduid cookie from Cloudflare

Question

Is there a Cloudflare setting that corresponds to the creation of the __cfduid session cookie?

I'm currently trying out CF; mostly for the neat DNS management and the implicit CDN. But the basic WAF is possibly just as nice an addition atop Apaches mod_security/CRS. However I'm not sure what said cookies purpose is, and would prefer to get rid of that.

The most obvious setting

Seems to also have essentially no effect on the creation of __cfduid with every HTTP response. The cookies purpose is presumably for opting out single users from firewall rules, repeated cloudflare captchas, etc.

Their support documentation alludes to that. Where the first revision from 09/2012 (https://support.cloudflare.com/hc/en-us/articles/200169536-What-does-the-cfduid-cookie-do-) says this behaviour can't ever be turned off. An entry two months later 11/2012 (https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-CloudFlare-cfduid-cookie-do-) however omits that note.

While Cloudflares TOS itself check out as plausible, this cookie has all the properties of a tracking session, dc41f5a78bc3e27d44b70fca4606e4262283407700773. The excessive cookie lifetime of 6 years is very odd for the exemplary internet cafe visitor use case. And since I'm personally avoiding needless sessions, and don't want to plaster a privacy note (in light of the infamous EU cookie law) like everyone else, I'd prefer to have it gone per default.

A workaround like:

  Header add Set-Cookie "__cfduid= ; path=/; domain=.example.org; HttpOnly"

Does eschew its storage, but retains two needless headers, and doesn't seem overly reliable.

So, is there another CF setting for this?

Solution 1

Steps for disabling a cookie -- php. I cant take credit for this its not my fix but im happy to spread the wealth.

function deleteSpecificCookies() {

    var cookies = document.cookie.split(";");
    var all_cookies = '';

    for (var i = 0; i < cookies.length; i++) {

        var cookie_name  = cookies[i].split("=")[0];
        var cookie_value = cookies[i].split("=")[1];

        if( cookie_name.trim() != '__utmb' ) {

            all_cookies = all_cookies + cookies[i] + ";";

        }

    }

    if(!document.__defineGetter__) {

        Object.defineProperty(document, 'cookie', {
            get: function(){return all_cookies; },
            set: function(){return true},
        });

    } else {

        document.__defineGetter__("cookie", function() { return all_cookies; } );
        document.__defineSetter__("cookie", function() { return true; } );

    }
}

Solution 2

What is the problem with this cookie? You are using their service and want to benefit from their service and their security – according to Cloudflare, this cookie helps especially for security reasons. Regardless of that, this type of cookie is exempt from the cookie law message:

However, some cookies are exempt from this requirement. Consent is not required if the cookie is:

· used for the sole purpose of carrying out the transmission of a communication, and

· strictly necessary in order for the provider of an information society service explicitly required by the user to provide that service.

Read more: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm

This Cloudflare cookie is definitely exempt from the cookie law.

Solution 3

No, there is no way to turn the cookie off if we are proxying the record (if you had a subdomain not running through our proxy in your DNS settings, then we wouldn't add the cookie because it is going direct to your server). The cookie is basically what makes security (like a challenge page) work.

Comments

[Synchro]

Aside from amusing things like this, the only available workaround is to proxy the connection and strip the cookie before it hits the client.

[mario]

"Makes security work" is still vastly indescriptive. How does it aid security against e.g. bots which aren't typically sending session cookies along? If it's just for CAPTCHAS then what's the excessive cookie expiry time for?

[MarcoCarnevali]

I suspect it's for establishing who is trusted, not who isn't trusted. If you don't have the session cookie, you are in the state of least trust. If you have the session cookie, you can be untrusted or trusted or anywhere in between. Thus, not sending the session cookie means you'll be treated in a more hostile manner by the WAF, not less. It would then follow that it has an 'excessive' cookie expiry time to stop you being needlessly pestered or throttled in future.

[Martin Algesten]

Turns out cloudflare hosts a lot stuff i often browse (api documentation, open source projects), which are all useless to me right now. No. I'm not going to enable random session cookie injection on domains that have nothing with cloudflare to do (like jqueryui.com, expressjs.com). __cfduid breaks internet standards. It's wrong.

[mario]

"for security reasons" is precisely the wishy-washy explanation which triggered this question. What is it used for now? Why is it still there when "security" features are disabled? Why does it have 6 years lifetime? The legal opinion on this is mostly orthogonal.

[Luca Steeb]

I'm afraid that anyone can answer this question regarding the security when even Cloudflare Employees (I assume that damoncloudfare is one) can't tell you, regardless of which reasons.

[dhaupin]

Here is one problem with this cookie: It triggers various false positives in vuln/PCI scanners. Example, Saintbot/Controlscan sees the response with a cookie bases session var and flags it as phprpc vuln, even though the phprpc is not present (404). Its annoying that we constantly fail scheduled PCI scans because of this simple cookie. Sure its the vendors fault, but after 20 or so attestations + tickets, and calling them out on it, they still haven't fixed the scan filter. Because of that failure to repair, this CF cookie causes PCI fail under the premise of false positive (still a fail).

[Luca Steeb]

I would say you should blame the scanners, not Cloudflare..

[Ray Foss]

The other problem aside from vulnerability scanners giving false positives is the performance impact, while it is negligible, it exists and it shouldn't.

[Synchro]

It's definitely not strictly necessary because everyone who hits a URL that sets it for the first time doesn't have it, yet the URL still works. If you you delete the cookie, it still works. In other words, it's not strictly necessary at all.

[Bits Please]

"service explicitly required by the user" I don't think my website visitors explicitly required that I use Cloudflare...:(

[We Are All Monica]

This is JavaScript code, not PHP, and it's a pretty bad idea. This code is redefining a built-in web browser property (document.cookie), and the way it is done will break any other cookies set by client-side script.