Cookies for beginners (Part 1)
Cookies are one of those topics that are equally important for developers and people that use computer mostly for their entertainment. Although it’s relatively hard to find movie scene with hackers talking about this part of the web, they are crucial not only for functioning of web application but also for many other areas.
They are commonly used for user tracking, which makes them part of privacy discussion. They enable developers to create state in HTTP protocols and are the most popular way to manage sessions.
But it’s not that common to dive into the inner workings of this mechanism. Too bad, because there are many great questions that could be asked in this matter. For instance, what are all those additional flags? What does it mean that cookie is secure? How do websites set cookies for other websites (yeah, that’s actually… never mind, keep reading)?
How does it work?
Ok, we will start small. Cookies can be sent by Javascript but they can also be part of the HTTP exchange. At the heart of it, it’s not some magic, just HTTP headers. Below you can see example of communication with the use of cookie headers.
Request:
GET / HTTP/1.1Host: tools.ietf.orgUser-Agent: curl/7.54.0Accept: */*
Response:
HTTP/1.1 200 OKDate: Sat, 17 Nov 2018 20:18:17 GMTX-Clacks-Overhead: GNU Terry PratchettSet-Cookie: logged=true
Request after setting cookie:
GET / HTTP/1.1Host: tools.ietf.orgUser-Agent: curl/7.54.0Accept: */*Cookie: logged=true
This enables users to create some kind of state mechanism despite using stateless protocol. If the server will respond with some identifier, client will send it in every request. With this information, server can link the next requests with a specific user.
If you tried to browse web with curl without cookie engine it wouldn’t be a piece of cake. You would have to add cookie to the headers with every request that you send. The question is — which cookies should you send? How long should a specific cookie last? Which domain can see what cookies?
All those questions are crucial for “state management” to work properly. If you started sending your cookies to domains that didn’t set them, you would get hacked in no time. Thus browsers implement multiple mechanisms to secure this process. Besides the cookie’s name, value and original host there are additional flags that inform about the use of the particular cookies.
These are: domain, path, expires, secure, httponly, path and samesite.
Rejecting cookies
I will be using the term “rejecting” in the next paragraphes. In some cases when cookie lacks some properties or they are not correct, browser will change them to default values. In other cases, they can be rejected. The most obvious scenario would be trying to set cookie for different domain.
Who wants a cookie? Domain and path flags
There is one basic rule when handling cookies: you can only set and access them for the origin domain. So, why actually do we need the domain property? It’s because sometimes we want to specify if a cookie should be visible also for subdomains. But there is couple of rules to follow here.
If you don’t set domain and path flags, default values will be used. For path it’s the current one, not /. So if we are on /root route, this one will be used. This prevents the browser from sending cookies to /public route but not to /root/things.
For domain, the default value is the original host. For example, if you request https://ietf.org, you can get this kind of response (cookie header added by me):
The domain is missing, so the cookie is set for the original host without dot in front of it. That means it’s not accessible for subdomains. In the browser, you will see:
If the domain flag is passed (and it’s valid), the browser will always add a dot. That means that all subdomains will have access to the given cookie:
https://ietf.org/Set-cookie: cookie=value; path=/; domain=.ietf.orgSet for domain „.ietf.org”Visible for subdomains such as: https://tools.ietf.org
https://ietf.org/Set-cookie: cookie=value; path=/; domain=ietf.orgSet for domain „.ietf.org”
So allowing subdomains for accessing cookies requires nothing more than a proper domain value. Also in contrast to the same-origin policy, cookies ignore the port and scheme of the origin. This means that although you can’t (without proper CORS configuration) read the Ajax response from http://example.com:66 to https://example.com or from https://subd.example.com to https://example.com, the cookies will be shared between them.
The root domain is allowed to set cookies that will be visible for all subdomains, but not for specific one. For subdomains the rule is similar - they can set cookies for all subdomains or only for themselves:
https://tools.ietf.org/html/rfc6265Set-cookie: cookie=value; domain=ietf.orgSet for domain „.ietf.org”https://tools.ietf.org/html/rfc6265Set-cookie: cookie=value;Set for domain “tools.ietf.org”https://tools.ietf.org/html/rfc6265Set-cookie: cookie=value; domain=trustee.ietf.org/html; path=/Rejected - trying to set from one subdomain to the otherhttps://ietf.orgSet-cookie: cookie=value; domain= trustee.ietf.org/html;path=/Rejected - trying to set from root to specific subdomain
The cookie will also be rejected when the developer will try to set it to the top level domain. That’s because browsers don’t allow users to create “supercookies” that would be passed to every domain with given suffix. You can search top level domains on this list — https://publicsuffix.org.
As you can see now, the domain flag in the cookie changes its scope. The interesting consequence of that is an inability to overwrite specific values:
https://ietf.orgSet-cookie: a=with; domain=.ietf.orgSet-cookie: a=withoutBoth set, both sent with request (Cookie: a=with; a=without)
Keep in mind that if you change the domain or path, you have to remove the old cookies first because the browser will send two versions of them and the order can be indeterministic. This doesn’t apply to the rest of the flags though.
The most important thing regarding the domain flag is to remember about setting it only for resources that need access to it. So if you have a big website with a lot of subdomains, ask yourself a question: do my subdomains need access to my session (or some other) cookie? If not, remember about setting it without dot. If you need to set some cookies only for moderators, you can always limit the path to /moderators.
Third-party cookies
Third-party cookies can be mistaken for “cross-domain” cookies. But it’s not the case. The rules for scope are exactly the same as for basic ones (one exception is samesite flag which will be covered in second part of this article). The difference actually lies in what the user sees.
If you enter https://www.youtube.com and you open the console, you can find the cookies storage confusing. In most browsers, on the left sidebar you will notice more than one page:
In the cookies panel, the domain attribute is set not only for the website that you are currently on:
Although you are browsing youtube.com, multiple other domains can actually set cookies with information about your activity. There are a couple of ways for youtube.com and let’s say, google.com to cooperate this way. For example YouTube can embed the iframe of Google on the website you are on. That way Google will be able to set cookies for itself in the response headers.
Those cookies won’t be different from any other cookies that Google sets. They are still only available for google.com, and they are still not available for YouTube domain. And they will be sent as all other cookies with a new request to google.com. The only thing is — you didn’t have to visit their website.
This behaviour is mostly used for tracking user activity. If you see an advertisement on one site with some customised content related to another website search or activity, it’s probably because of cookies. That‘s why some browsers are disabling them by default. If you haven’t done it yet, I recommend it. You will probably have the same website functionality with much more anonymity.
That’s all about the basics and scope of cookies. In the second part, I will describe the rest of the flags and hopefully give you a better understanding of how you can easily increase your cookies security.
