Are Cookie Banners a Waste of Time or a Complete Waste of Time?
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|
New YouTube Video Series: Everything you ever wanted to know about DNS and more!
You may have heard sayings like "If it is broken, it is probably a DNS problem. And if it isn't DNS, it is still a DNS problem". Or "Everything that happens on your network is reflected in DNS.". DNS is a great protocol, sometimes shamed for things it can't help itself with, and sometimes forgotten (if it works well). One of the amazing things I find about DNS is all its little nuances and how it all "fits together". I planned this video series a couple months ago, and figured that this would be easy. I know DNS... but each time I look at DNS, I learn something new, so it has taken a while to get the first episodes together, and today I am releasing the first one. No fixed schedule on when they will be released (weekly?... if DNS doesn't prevent me to post them). No fixed end... not done yet considering topics and ideas.
You can find the first episode here: https://www.youtube.com/watch?v=b8-f-vvygU4
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
And Ransomware Just Got a Bit Meaner (yes... it is possible)
Ransomware has been evolving, and each evolution appears to be a bit "meaner" than the first. Early ransomware targeted consumers. Encrypting baby pictures, or tax records, motivated users to pay in some cases a few hundred dollars to get their data back. The attacker went for easy targets and with that for easy money. But as most people dealing with consumers can attest to: Customer support is hard! Many consumers do not know how to use crypto currencies. Even the relatively straightforward Bitcoin payment can be too difficult. And forget about currencies like Monero that are often not traded on mainstream exchanges.
Next came ransomware targeting enterprises. Payouts quickly reached millions of dollars. The influx of new money lead to the rapid development of more sophisticated methods to attack enterprise networks to plant ransomware. Attacks lasted weeks or months and not seconds. The attack carefully figured out how to cause the hardest to a particular entity and create sufficient urgency to pay the ransom, even if backups were available but too difficult to retrieve and install.
But attackers didn't stop here. Next, we had "extortion ware". In addition to encrypting the data, attackers exfiltrated the data and threatened to leak it. Companies like Quanta computers are said to have paid tens of millions of dollars to groups deploying this kind of software. Of course, if the organization doesn't pay, the attacker needs to find a method to release the data. This happened now to the Irish Health Services with what may be devastating consequences [1]. The ransomware attacker not only leaked private health information after a ransom payment was category denied. In addition, other miscreants, or the original attackers themselves, are now using this leaked data.
Apparently, individuals in Ireland are receiving calls claiming to come from the Irish Health Service, asking for banking information. The caller is using leaked data (personal information like birthday and address, but also the date and type of recent medical procedures) to authenticate themselves. The victim is then asked for banking information for a "refund".
[1] https://siliconangle.com/2021/05/19/information-stolen-ransomware-attack-irelands-health-service-shared-online/
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Comments