Protecting Your Cookies from Hackers and Hungry Developers!

Hey, everybody. Welcome to my talk, Protecting Your Cookies from Hackers and Hungry Developers. My name is Mohamad. Everybody calls me Mo. I'm a passionate code bizarre at ING Bank in the Netherlands. I have 15 years of experience in the industry. We are a family of four. I have two kids. I love playing video games alone and with the kids. I'm starting for sharing knowledge. So that's why I'm here today.

So today is all about cookies. So let's first take a look at the cookie name itself. When does it coin? So Lou at Netscape was developing an e-commerce application. As you know, e-commerce applications need a cart. So a cart, it means that you should store what are the cart items. So in order to do that, so he went for a logic that right now we know it as cookies. So it was mostly about storing a small chunk of data in the client browsers, in your client browser. So it means that we are not going to send it to the server. It just stays there. He named it Cookie. And actually, the cookie name itself came from magic cookie. You know, back then, whenever two programs wants to in Unix and Linux environment, they want to communicate with each other and send data. They use the term magic cookie to send this kind of data. So that's why Lou from Netscape picked the cookie from magic cookie. And these days, we know cookie.

So let's start from the beginning. So where does this cookie, where do we store it and how does it work? So whenever you open the browser, go to Google.com, you're going to send a request to the Google.com, right? It goes to the server. It generates a response for you and it contains some headers. This is the place that cookies come into play, which is a header, a header named set cookie header.

Whenever the browser, our browser sees, you know, send a cookie header. So it's going to store it some, right? Yeah. There's a cookie storage, which I'm going to discuss later. So the cookie is there. But after that, what should we do with that one? So it means that in the next request, on the requests that are coming after that one, those cookies should be included in the request as well, because we just store something on our machine. We should send it to the server. Just imagine that it is a token.

So the request, whenever we send the request, actually the browser sends the request, it includes some headers again. One of those headers is cookie header. So whenever our server sees the cookie header, it can interact accordingly. Maybe it is an authentication token and so on and so forth. So we know how does cookie work and where are the places that we are sending that. It means that inside the request and inside the response.

But how does the browser store it? There is a cookie storage on your machine. Imagine somebody has unauthorized access to your machine. So it means that they can steal those cookie files and then they can have an attack like a session fixation or session hijacking. So let's see how does that work. If I go to this folder exactly, it means that on your Mac, for instance, user, your username, library and then application support. You can see a folder named Google or Firefox. So Google and then go to Chrome, your default. It means your default profile or other profiles would have different names. I'm going to see a file named cookies. Nice. It is a document without any extension. I'm going to drop it somewhere because we can check it out together. So I just dropped it, dropped the cookie in this folder. So let me open my favorite database. I'm going to select SQLite, open, go to that folder, click on cookies, finish. Nice. It is the SQLite database.

So if I go to the tables, I can see cookies, right-click, view table, voila. All of my cookies are here. All the websites that I visited and all the cookies names and values. But as you see, the value is encrypted. For Chrome, it's encrypted. For Firefox, it's not encrypted. There's a full article there, which later on you can check it out. It is on my MindMap. Later I will share the link to all MindMaps and the source code that we're going to check today. No worries.

So you might wonder, the value is encrypted, but can I decrypt it? Of course. Even you can decrypt that one on your machine. If you open any terminal and use security commands on MacOS or in Linux environments or Windows, there are other ways. Some of them is a plain text value, which is stored in the JSON file. No worries. But in Mac, at least it's a little bit more secure. So if you use security commands, find generic password, dash W, which shows us the password, the application name, ChromeStorage is a Chrome safe storage.

It means that unauthorized access to our machine is so dangerous and they can find all of our passwords. This is the part that is about authorized access. But when it comes to which we can secure, our company maybe does that, we have a lot of tools to take care of that one. But when it comes to cookie itself, we should know how the browser parses the cookie and how it interacts with the cookie itself. So what are the parameters that we can set to make it more secure to protect our cookies? So as you know, whenever we set the cookie, there are a couple of attributes that we can set.

So what are the parameters that we can set to make it more secure to protect our cookies? As you know, whenever we set the cookie, there are a couple of attributes that we can set. One of the cool things about the name is that it can have some prefixes, like underline secure, which forces the cookie to be secure. Another example is underline HTTP, which enforces the HTTP only property to prevent attacks.

The value itself is crucial as well. If we don't generate the value in the correct format and data type, it could lead to session fixation or session hijack attacks. For instance, setting a cookie can be as simple as logging in as a user to generate the cookie value. The value of the cookie can appear random, but it holds significance in terms of security. Decoding cookie values can reveal vulnerabilities and issues that need attention to secure the application.

Ensuring the proper attributes like secure and HTTP only for cookies enhances security. Understanding the significance of the value generated for a cookie is vital to prevent session-related security risks. Proper encoding and decoding of cookie values play a crucial role in identifying and addressing application vulnerabilities. By examining the decoded values, developers can assess and improve the security measures implemented within the application.

For instance, I have an application here. Let me open developer tools. Cookies, I don't have any cookies, but I can click on login as Mohammed to login as Mohammed. So it's going to set the cookie for me. So it's simple setting a cookie. No big deal.

Let me see the cookie value. Yeah, it just created a cookie value for me. The cookie value is this one. So just imagine that I didn't, as you see, the value itself, it's a random characters next to each other, but in reality, it's not random.

Let me copy that one and try to decode this one to see what are the issues of my application in order to set a cookie. So if I open Burp suite, go to the decoder, paste my value. As you see, it has already detected. It is red. So it means that I can decode it as a URL. Nice. I can see equal, equal, it means that I can decode it as a base 64 most of the time.

Nice. So it was a plain text that they put in their cookie. So it means that, okay, nice. So I can change it to admin instead of Mohammed. I can encode it as a base 64 and copy the value and come here.

Let me go to the homepage first. In the homepage, my username is Mohammed. Let me replace it with the new one, refresh the page. Voila. I'm admin right now. Voila, no. So that's the point. So the value is very important.

Next attribute is domain. Domain is related to which domain and subdomain has access to this cookie. By default, if I set a cookie, for instance, in this case, my authentication cookie, if I go to one of my subdomains like sub.victim.local, let's see whether I have access to my cookie here or not.

So as you know, here I have access to the cookie. Perfect. My cookie is there. There is no message coming. There is an image. By the way, keep in mind that the image that I use in this application is behind authentication. That's why you can't see that. So, OK.

In subdomain, as you see, I can't see anything. That's the thing that I wanted. But the point is, if you set current domain, it's going to be available in subdomains as well. So if you in your application try to set your domain like this, it's going to be available in your subdomains as well. Or the domain could be like that with a dot.

So all subdomains, which we are not intended. So keep in mind, domain is very important. Path is the path that you want this cookie would be available. So in this case, I want this cookie available throughout my application. So the path is root. Regarding the path, the default value is current. So it means that if you don't set it, it's going to be your current path. So if it is ABC, ABC, it's going to be ABC, ABC. But in most that tools that we are using these days in Node.js, JavaScript and stuff, they're going to set it by default to the root.

So the other two that are important and that can lead to a vulnerability are expires and max age. Both of them are related to expiring that cookie on people's machines. The first one expires has the format exactly like this. The week of date, then comma, the day of the month, month's name in three, and word for the three-character format, and year, and so on and so forth. So for this one, it just set the expiry date to this one.

Max age and the format couldn't be anything else. It's always like that. And it's too big. I don't like it, to be honest. But max age, it's a little bit different because it uses milliseconds and has a priority over expires. So it means that expires is they just for maybe legacy, but max age is the preferred one. If both of them show up, it's going to pick max age.

But the most important thing in this case is not expiring the cookie on people's machines. We should expire it at the server side as well, because maybe somebody has already hijacked our cookie so they can use it later on. So expiring on the client side is not the only option for sure. You should expire it at the server side as well, which could lead to a vulnerability. The other one is secure. Maybe you can guess it as well. We discussed it a couple of minutes ago. Under underlying secure, what does it do? Actually, it makes our cookie HTTPS only available in HTTPS, not in HTTP.

And also, if you don't set it by default, it would be for HTTP. So HTTP and HTTPS put always secure there to make sure that your cookie is available only in HTTPS mode, because otherwise you won't have encryption. HTTP only is very important because if your application has an XSS attack, so people can easily access document.cookies which reveal your cookies in all applications.

So if I put a document.cookies in all websites, you can see that my authentication token is there. But if I go to application cookies and set the HTTP only true, if I try to get cookies again, it's not available. So what does it mean? It means that if I have a vulnerability, XSS vulnerability, and I forgot to set the HTTP only to true.

So if an attacker sends me a link like this, there is a free promo code for your website. So I'm eager to click on that one, right? So as you see in the message, it tries to use injecting the script tag because my application right now has an XSS vulnerability. So the attacker sends you the message, your promo code is free 2026. Yeah, all good. I can see the one. But if I open developer tools, go to the console, and refresh.

Wait a moment. What is our cookie right now? It's HTTP only. Let me remove HTTP only first. Yeah, refresh to make sure that, yeah, it's not HTTP only. If I refresh, it doesn't let me use it. It's better to log in again. Give me a second. No cookies, no cookies. Attacker link is there. It's just refreshed. So HTTP only is in order to prevent all XSS attacks to access your cookies. Right now, I don't have any cookie. I just logged in. It's not HTTP only. I can come here. Nice. Let me use the same one. Perfecto. If I go to the console, I can see that I can see my cookie because otherwise, as you see, as you remember, the previous log didn't contain anything. Why? Because they tried to inject in script tag. So because my website had an XSS attack. Nice.

Let's move on. So, yeah, as you see, if they have access to your cookie name, so it means that they can attack your website using session hijacking attack because they have your session, which is somehow the same. It's different from fixation, but the fixation could happen if they have access to your file as well. So maybe a same site for me is the most important attribute that you can set for an application which is related to literally same site. Before getting to the same site, I want to make sure that we know the differences between same site and same origin. Same origin is the error that we always get from time to time when we are calling the API as a front-end developer, React developer. What is it? It is related to the origin of a URL when you are calling the backend on a different port or a different hostname. The origin is a combination of port, hostname, and scheme.

So port, hostname, and scheme. So in the hostname, it might be www.example.com, api.example.com, frontend.com. It could be anything, right? So these are what we call origin. But when it comes to the site, it's a little bit different. Port is not included. Top-level domain is included, which is .com, .nl, .it, and so on and so forth, .org. And top-level domain plus one. So it means that example.com, the subdomain, www, api, and all of them are not considered. The scheme, of course, is part of that one as well. HTTP or HTTP only. So this is the thing that we call same origin because they are coming from the same origin.

But sometimes it's become a little bit complicated. Like GitHub.io, GitHub.io, if we consider only top-level and top-level plus one. So it means that GitHub.io, just imagine that under the same project, we're going to have under the same domain, which is GitHub.io. For sure, we're going to have different projects for GitHub because all of them have their own page. So if we consider these two as the origin for this domain, it's going to break others. So it means that all projects can have access to each other's domains.

So in this case, there is a public suffix.org list. It is all the E top-level domain. So it means that for GitHub.io, top-level domain is not I-O, it's GitHub.io. So the E top-level plus one would be project.github.io. So in this case, because project is part of the URL, so it means that origin. So it means that everything would be fine. So they are not considered as the same origin. If you want to check out the list, yeah, definitely check out the whole list, which is here. If I look for GitHub.io, definitely I can find it because this one is considered a top-level domain. An E top-level domain is better to say. So if you don't set the same set correctly, you're going to have cross-site request forgery attack and server-side request forgery attack. How? Because there are different values for them. One of them is none, lax, and strict.

When you set it to none, first of all, secure flag is required, so it means that it should be always HBPS. Whenever you set it to none, it means that it's not going to check for two domains to be on the same site. So what does it mean? It means that if I come here, I set same site to none and secure to true. So if I try logging fast, I'm going to log in to see my cookie. My cookie, as you see, is same site is nothing and secure is nothing. By the way, keep in mind that whenever the same site is none, it's going to consider it by default lax. Now it's secure as well. Just imagine an attacker wants to attack my application by getting one of the resources that is under authentication, which is my image. Let's see whether attacker website attacker.local can have access to that one. Let's wait for the response in the meanwhile. So this is none. Secure flag is required and cross-site tracking system, which I'm going to tell you in a moment. So it means that attacker could get some of my resources, which are behind the authentication. I don't like it. So this is none.

The other one is lax. If you set it to lax, it's going to be a little bit relaxed. But let me show you a strict as well. So if I try to log in with a strict. Right now, same site is strict. My application works fine. Let's check attacker. Attacker doesn't have access to my cookie. Awesome. But the thing is, whenever you set it to a strict, it's going to be so strict. So it means that if another application like gmail.com, just imagine this is gmail.com. They put a link to your application like this one. If I click on that one, as you see in the initial request, I don't have access to my cookie. See, different between these two. Both of them have the image.

Because I am behind authentication and the image is not the first request that we are sending to the server. So strict is so strict in that term. So if you want to prevent this one, if I receive an email from booking.com and people click on that link, open the booking.com, and they don't see that they are logged in. So it is a problem.

The default value and the value that is there to set is lax. Lax is a bit relaxed, as I mentioned. Right now, it's lax. If I go to the attacker website, for sure I'm not going to see the image anymore. But let's try the victim application to see whether that one works normally or not. Yeah, let's click on that one. Yeah, see, I have access to the cookies. The cookies are available in both of them at the same time. Nice.

So I discussed about everything, and there is an article that I want you to check out. It is same-site cookie explained, definitely suggested. So take a look at this one, because it's going to explain why previously the same-site default value was none, which caused a lot of vulnerabilities. Google and the web community decided to set the default to lax. As you know, lax doesn't have that vulnerability that we just discussed, like this one, and it doesn't feel strict, which doesn't lead us to set the cookies for top-level navigation. Awesome.

And also, I suggest you take a look at the Chrome privacy settings as well. Chrome settings privacy. If you go to third-party cookies, you know third-party cookies, it's all about the cookies that are set to none, which, as you see, as I mentioned, if you set the cookie to none, other applications can send the cookie along to your website. So it means that if you are an advertisement service, you can keep track of people visiting different websites. So if you set them to block, it's going to be blocked for good. Nice.

And also, another point about this one, by default, if you go to incognito mode as well, so everything by default is blocked. So last but not least, partitioned attribute. Partitioned attribute is very cool, and I really like it. As I mentioned, whenever you use the same site and you set it to none, you can use that cookie between different domains, right? Because it's not going to check for the same site. Because I'm going to use it for storing different things across different websites. But there is a property attribute that you can set for your cookies, which is partitioned. Partitioned is there exactly to fix the privacy issue of the cookies with none, but not disclose your information. So how does it work? Just put partitioned attribute for your cookie, and we call it chips, actually. Cookies having independent partition states. It's not named somehow. It mostly feels like a sentence, but chips in short.

So if you use chips, it's going to partition your cookie. It's going to make a key for your cookie, your embedded cookie, and the top level, the parent website. So it means that your cookie would be different in different applications if they use it. Let me show you a picture in the privacy sandbox at google.com, which makes more sense to you. This one. Whenever it is unpartitioned, whenever you don't have partitioned property, the cookie would be shared between application A and application B. Application A, in this case, for us, is our victim. C is the cookie that I set for the victim as well. But B, it wants to use B, which is attacker, wants to use a cookie from victim application, which, in this case, it's not acceptable. We want to prevent this one, or having some kind of privacy issue, keeping track of users. But you want to have this feature to have a cookie and store something. In this case, you can put partition. Partition would consider A and C and as a key for your cookie jar.

So the cookies won't share between each other. The C has its own cookie. The C website has its own cookie when it loads it in B. A has its own cookie when it loads it. C has its own cookie when it loads it in A application. So there are a lot of possibilities that you can use chips.

For instance, for weather embedded widgets, for chat widgets, if you want to store some preferences. Even if I open developer tools here, no here, for instance, because we have an embedded script from YouTube. So if I go to application, my domain, as you see, we have some partitioned cookies in this case, which they belong to YouTube.

Because I just loaded an embedded iframe or an embedded script, which loads data from youtube.com. So in order to not keep track of users, I don't know what do they do with that cookie, but long story short, it's related to that one. And also, whenever you have partition, the secure flag is required as well. That's the whole story of cookies. If you want to learn more about cookies, you can go to my GitHub cookies workshop.