What is a cookie and why is it used?

HTTP is a stateless protocol, which means that it can’t distinguish between 2 consecutive requests originating from the same computer or network or user. This was a major problem. Due to this, a user couldn’t maintain its session and if we were to continue with the same thing, the internet would be the same as it was a decade ago, comprising just a bunch of static html pages. No user accounts, no customization, etc and if there are any user accounts you need to login again and again to access each page.

To solve this issue, HTTP had to be made stateful. The answer was a cookie. Unlike the cookies that you have for supper, these are small files created by the website that you visit. They are generated by web applications and stored in your web browser and exist in the form of key-value pairs.

An example would be PHPSESSID: xyjaez1081lze23, lang: en

Let us understand this with an example. Suppose you go to a store and bring back some utensils. When you reach home, you find that one of them is broken. So, you go to the store owner, and tell him your problem. But to your dismay, he replies that he doesn’t know you. This was the initial condition of HTTP without cookies. The web server wouldn’t recognize you at any cost.

Now consider a different scenario. The store owner gives you the receipt. The receipt has a number. The number is unique and can be used to recognize you. He also has a copy of the number stored on his computer. When you return to the store, he asks you for the token. He matches the number with the one on his computer. He then recognizes you. This is exactly what cookies do and is no different than a token used to remember you.

They can also be used for various reasons. Such as:

1. To remember your language preferences. For example, the lang cookie, above, has been set to en. Since they have been saved on your browser, it’ll be sent to the site that saved it in the first place. This web application will parse it, and send you an English version of the site.
2. To track you. They can also be used to track your country, city, etc.
3. The number of times you’ve accessed a free service.
4. The most important of all, to keep your session data.

What are the different flags used in a Cookie?

They might be small files, but each cookie in itself has a complex structure. What makes it complex are the different flags that can be present with each cookie. These flags are nothing but attributes to cookies meant for different purposes or just like names to the values which can be used to identify those numbers.

Let’s go through all the flags briefly.

1. Secure: It can either be set to true or false. If set to true, the cookie will only be sent if the connection is HTTPS. This can be used to mitigate the risk of the MITM attack in which the attacker forces the user to browse the website on the HTTP. If this flag is set the cookie will not be transferred over HTTP.
2. HttpOnly: If set to true, client-side JavaScript will not be able to access the cookie. This can be used to save the cookie from the XSS attack which steals the cookie. So client side javascript will not be able to access the cookie
3. Domain: Contains the domain or subdomain to which the cookie can be sent.
4. Path: There can be different things on each path. If the developer wants to set a different cookie for each path, he may use the path attribute to accomplish this.
5. Expires: Used to define the validity of the cookie.
6. SamePath: Used to define conditions as to when the cookies can be sent during cross-site requests.

What is the domain attribute and how it is being used in Cookie?

Now let’s expand upon the domain attribute of a cookie. As the name suggests, it is used to hold the domain and subdomain name. It can then be used by browsers as to which domain/subdomain the cookie needs to be sent and from which it needs to be refrained from.

Alternatively, you can also think of it as setting up the scope of a cookie. A Web application can have multiple sub-domains and each sub-domain can set up its own cookie.

Let’s suppose that the website www.example.com has 4 subdomains and each subdomain is running a different website on different frameworks. They set their own cookies.

The table below explains it well.

So, if you visit www.example.com, the web application will provide you PHPSESSID: wwwexample1, as a cookie. It will be saved by your browser and when you send a request back to www.example.com, your browser will send the exact same cookie to the web server. Basically it identified the domain attribute in the cookie and if you are visiting the same domain that is mentioned in the cookie, the cookie will be included with the request.

If you visit, sub1.example.com, the web application will set, for instance, JSPSESSID: sub1.example2, as a cookie. Though the domains are same, which is example.com but the sub-domains are different. So, if you send a request to sub1.example.com, your browser will send JSPSESSID:sub1example2 as a cookie to the web server.

Same Site Cookie

This is a new attribute that is now being used by modern browsers.

Let’s first understand what are first party and third-party cookies:

A first-party cookie is one that is set by a website that has the same name as the domain that is currently being visited, as displayed in the browser’s address bar. A third-party cookie is one that comes from a domain other than the one that the user is currently on.

So basically, the same site attribute fixes a couple of vulnerabilities which take advantage of the domain attribute in the cookie (if the request is being sent to a domain that is set in the cookie, the cookie will automatically be included) such as CSRF.

So, if a user is getting redirected from abc.com to bcd.com and the browser has a cookie with the domain bcd.com, it will be automatically included in the redirection request. But if the same site cookie attribute is set, the cookie will not be included in the redirection request.

There are two flags in the same site attribute.

Strict

If the strict attribute is set so even when the user follows a regular link, the strict option will prohibit the cookie from being transferred to the target site by the browser.

Lax

The lax value is a good balance between security and usability for websites that want to keep users logged in after they come from an outside link. So, if a user is following the regular link, the cookie will be included in the request.

Conclusion

Cookies have made a significant contribution to making the web stateful, but they also add to the attack surface. They can be used by adversaries to gain control of privileged functionalities, perform SQL injections, session hijacking, and account takeover. OfCourse, all of this depends heavily on the type of application and the functionality provided by the web application and its dependence on the cookies. There have been instances where attackers have been able to get access to hidden functionalities only accessible to administrators by just flipping the values in cookies.

As a developer you must check what are the functionalities that the web application provides and how are the cookies integrated with the web application. The cookies, especially the session cookies, should be hard to guess and the appropriate flags/attributes must be set as per your needs.