[SANS ISC] Are Cookie Banners a Waste of Time or a Complete Waste of Time?, (Thu, May 20th)

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Source: Read More (SANS Internet Storm Center, InfoCON: green)

You might be interested in …

[ThreatPost] How to Get into the Bug-Bounty Biz: The Good, Bad and Ugly

All posts, ThreatPost

Experts from Intel, GitHub and KnowBe4 weigh in on what you need to succeed at security bug-hunting. Source: Read More (Threatpost)

Read More

[SecurityWeek] US Pipelines Ordered to Increase Cyber Defenses After Hack

All posts, Security Week

U.S. pipeline operators will be required for the first time to conduct a cybersecurity assessment under a Biden administration directive in response to the ransomware hack that disrupted gas supplies in several states this month. read more Source: Read More (SecurityWeek RSS Feed)

Read More

[TheRecord] PrintNightmare vulnerability weaponized by Magniber ransomware gang

The operators of the Magniber ransomware have weaponized the infamous PrintNightmare vulnerability and are now attempting to breach Windows systems in South Korea. In a report published today by security firm CrowdStrike, the company said the attacks have been taking place since at least July 13. Which PrintNightmare is this? While several different vulnerabilities in the Windows […]

Read More

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.