[Перевод] All about cookies and their security

What are cookies and why are they used?

HTTP is a static-free protocol, which means that it cannot distinguish between two consecutive requests originating from the same computer, network, or user. This was the main problem. Because of this, the user could not maintain his session, and if we continued like this, the Internet would be the same as it was ten years ago, consisting of only a bunch of static html pages. No user accounts, no configuration, etc., and if there are any accounts, you have to log in again and again to access each page.

To solve this problem, HTTP had to be made stateful. The answer was a cookie. Unlike cookies you receive, these are small files that are created by the website you are visiting. They are generated by web applications and stored in your browser as key-value pairs.

An example would be PHPSESSID: xyjaez1081lze23, lang: en.

Let’s understand this with an example. Suppose you went to the store and brought dishes from there. When you get home, you find that one of them is broken. Then you go to the store owner and tell him about your problem. But, to your horror, he replies that he does not know you. This was the original state of HTTP without cookies. The web server will not recognize you in any case.

Now consider another scenario. The shop owner gives you a check. There is a number on the check. This number is unique and can be used to identify you. He also has a copy of the number stored on his computer. When you return to the store, he asks you to show your receipt. He checks the number against the number on his computer. After that, he recognizes you. This is exactly what cookies do and is no different than a receipt used to remember you.

They can also be used for various reasons. For example:

To remember your language preferences. For example, the above lang cookie was set to en. Because they were saved in your browser, they will be sent to the site that saved them in the first place. This web application will parse it and send you the English version of the site.
to track you. They can also be used to track your country, city, etc.
The number of times you accessed the free service.
And most importantly – to save data about your session.

What are the different flags used in a cookie?

These may be small files, but each cookie has a complex structure on its own. What makes it complicated is the various flags that can be present in each cookie. These flags are nothing more than cookie attributes for various purposes, or simply names of values that can be used to identify these numbers.

Let’s take a quick look at all the flags.

secure: Can be set to either true or false. If set to true, the cookie will only be sent on an HTTPS connection. This can be used to reduce the risk of a MITM attack, in which an attacker forces a user to browse a site over HTTP. If this flag is set, the cookie will not be sent over HTTP.
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 an XSS attack that steals the cookie. So client side javascript won’t be able to access the cookie.
domain: Contains the domain or subdomain to which the cookie can be sent.
path: Each path can have different things. If a developer wants to set a different cookie for each path, they can use the path attribute to achieve this.
Expires: Used to determine the expiration date of the cookie.
SamePath: Used to determine the conditions under which cookies can be sent in cross-site requests.

What is the domain attribute and how is it used in Cookies?

Now let’s take a closer look at the domain attribute on the cookie. As the name suggests, it is used to store the domain name and subdomain. It can be used by browsers to determine which domain/subdomain to send the cookie to and which one to refrain from.

It can also be considered that this determines the scope of the cookie. A web application can have multiple subdomains and each subdomain can set its own cookie.

Let’s assume that the site www.example.com has 4 subdomains, and each subdomain runs its own site on different frameworks. They set their own cookies.

The table below explains this well.

Cookies for relevant subdomains

For example, if you visit www.example.com, the web application will pass you the 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 has defined a domain attribute in the cookie and if you visit the same domain as the one specified in the cookie, the cookie will be included in the request.

If you visit sub1.example.com, the web application will set, for example, JSPSESSID: sub1.example2 as a cookie. Although the domains are the same, i.e. example.com, but the subdomains 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 Cookies

This is a new attribute currently used by modern browsers.

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

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

Thus, the “same site” attribute fixes a couple of vulnerabilities that use the domain attribute on the cookie (if the request is sent to the domain specified in the cookie, the cookie is automatically included), such as CSRF.

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

There are two flags in the same site attribute.

Strict

If the strict attribute is set, then even when the user follows a regular link, the strict option prevents the browser from passing the cookie to the target site.

Lax

The lax value is a good balance between security and usability for sites that want users to stay logged in after clicking on an external link. This way, if the user clicks on a regular link, the cookie will be included in the request.

Conclusion

Cookies have made a significant contribution to website transparency, but they also increase the attack surface. They can be used by adversaries to take control of privileged functions, perform SQL injections, hijack sessions, and take over accounts. Of course, this all depends to a large extent on the type of application and the functionality provided by the web application and its reliance on cookies. There have been cases when attackers managed to gain access to hidden features that are available only to administrators by simply changing the values in cookies.

As a developer, you should check what functionality the web application provides and how cookies are integrated with the web application. Cookies, especially session cookies, should be subtle and the appropriate flags/attributes should be set according to your needs.

Original article – here.
Support the author by clapping on Medium.

The translation of the article was done by the Enthusiast Translation Project: