Are Cookie Banners a Waste of Time or a Complete Waste of Time?

Published: 2021-05-20
Last Updated: 2021-06-10 12:08:59 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Legislation, in particular in the European Union, has led to a proliferation of "Cookie Banners." Warning banners that either ask you for blanket permission to set cookies or, in some cases, provide you with some control as to what cookies you do allow. These regulations emerged after advertisers made excessive use of HTTP Cookies to track users across different sites. But in my opinion, these measures are often implemented poorly. Changes in browsers have made cookies far less menacing than they have been in the past due to changes made in browsers. Other tracking technologies are bound to replace cookies and, in some cases, already have.

There are very legitimate uses for cookies to track a user's session. In my opinion, a proper session cookie has the following properties:

  • It is restricted to a specific hostname (e.g., "isc.sans.edu")
  • It has the httponly and secure parameter set ("same-site" is nice to have, of course)
  • There is no expiration time, so the cookie will get deleted as soon as the user closes the browse. This defines a "Session Cookie." 
  • For extra-extra credit: Start the cookie's name with __Host or __Secure prefix.

Many sites will set various additional cookies, and often they are inserted by middleware. As I hate "shaming" others, let me use isc.sans.edu as a bad example. 

% curl -si https://isc.sans.edu | grep Set-Cookie
Set-Cookie: visid_incap_2188750=FYohHlwAB06WoVxsdKMnPSB4tsf5BK; expires=Fri, 10 Jun 2022 09:40:10 GMT; HttpOnly; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: nlbi_2188750_2100128=4jQpYhNNrz5qk8KuDW1UNgAAAADjVqz5zQSu/0YJRz/fEYuM; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: incap_ses_1243_2188750=v0+KUhJRlXC7EJCHVwZAEePvwWAAAAAAE0OXILjXlfNemg/mxkNCeQ==; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: ___utmvmpOBuREXZZ=OcBPfJZKGQA; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvapOBuREXZZ=qloSeVq; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvbpOBuREXZZ=MZL

Pulling in the index page for the site, you actually do not get a session cookie at all. This is because all these cookies are set by our CDN/WAF (we use Imperva's service for that). All CDNs will add cookies to track user's sessions. Cloudflare for example explains its cookies [4].

Comparing this to dshield.org, which doesn't use Imperva:

% curl -si https://dshield.org | grep Set-Cookie
%

Using a simple curl script and checking the top 100 sites (according to majestic.com), About 30 are setting cookies right as you download the index page before having a chance to approve them, as tested with a simple curl script. Testing with a real browser shows many more "hits."

Here are some of the current limits to cookies in modern browsers:

  • The RFC requires browsers to track at least 50 cookies per site (and 3000 total) [1]
  • The maximum amount of data allowed per cookie is at least 4kBytes (some browsers allow more)
  • If no "SameSite" property is set, browsers will now typically use "lax," not "none," so you get some basic CSRF protection by default
  • Third-party cookies, or the ability to set cookies for another site, are pretty much dead in a modern browser

A "Cookie2" header was introduced to distinguish proper session cookies from regular cookies in the past. But this header never really took off and has since been deprecated. [3]

Sites that do use cookies banners to allow users to select what cookies they want have also gotten crafty in tricking users into allowing them via "dark patterns." You will typically first see a dialog asking you for blanket permission to set cookies, and you need to review a second dialog to select particular cookie types. Precious seconds will delay you from getting to the content (and as a result, the user will often "approve" the first dialog).

[1] https://datatracker.ietf.org/doc/html/rfc6265
[2] https://www.whatismybrowser.com/detect/are-third-party-cookies-enabled
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie2
[4] https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Keywords: banners cookies
1 comment(s)

Comments

How effective are the "Block third party cookies" options in browser settings? Are organizations using this option? Great article, many thanks!

Diary Archives