So the other day my father and I had one of our infamous tech discussion, one of the kind were the people around us would start a side talk as the two of us would got lost in our topics. One of the subjects we came across, was cookies and he told me he disables them and then selectively enables cookies for a few pages. He also told me, why he does so and it came down to two reasons. First, he is concerned about his privacy – and that is good, we all should be more concerned about that! The second reason is security and the lack of secure cookies. Cookies are not evil in themselves, they are, however, often implemented poorly and therefore I can understand both concerns. So, let’s see how to tackle cookies in the web.

Why do we need Cookies at all?

Well, first we need to understand that HTTP, the protocol that we use to surf the web, is stateless. When we browse to a web page, such as this one, our browser establishes a connection to that page and requests data for that URL. The web server that is hosting the page respons with data and closes the connection. Job done. If we navigated to a link on that same page, the entire process would repeat, just for a different URL. The web server would have no idea who we are and where we come from. But it’s a common behavior for a website to remember the visitor. Just think of facebook, they need to know which user is performing which action. That’s what cookies are for. Cookies store data as key/value pairs, so when you log into a web page, such as facebook, the web server does not only send the data for the web site, but it might also generate a random ID, assigns it to your user account and asks your browser to store something like “user=3kjwdhf38wh324e98uz”. So when you navigate to a subsequent link, your browser will send that key/value along with the request for the new URL and the web server now knows which user is hidden behind that string. Because the server had that string assigned specifically to you. The server can recognize you. That’s what cookies are for.

First-party Cookies vs. Third-party Cookies

Cookies are differentiated into two groups, first-party and third-party cookies. What I just described would be a first-party cookie, the website itself created the cookie and it is used for that site itself. What my father meant by “concerned about privacy” is more targeted towards third-party cookies. It is widely common these days to implement e.g. advertisment on websites and display ads that are of interest to us. Therefore ad providers need to understand the interests of all their visitors and that’s why these services also want to store cookies and recognize you on different web pages. These cookies are not created by the website you are visiting, but by the ad provider, a third-party. If you visit another website a little later and they integrate the same ad provider, this provider will recognize you again and know that you visited not only this site, but the one before as well. With a bit of analytics, like how often you visited sites of a certain topic, the service can basically find out, what your interests are, your political opinions and a ton more. Their use is widely questioned in the web and many browser disable them by default nowadays. But we need to be aware of these to different kinds of cookies

Threats with insecure cookies

Let’s go back to the log on scenario. Say, you logged on to facebook and received a token, one such as I mentioned above. What happened, if someone could steal that token from you? Would that person be able to pose as you and lead the website to believe that he or she was you? Absolutely! If you were logged in to facebook and facebook didn’t secure their tokens, I could try to steal it from you and then visit facebook logged in as you. That’s what we refer to as Session Hijacking. I would have hijacked your facebook session. By default cookies are not secure and that is were the developers come into play.

HttpOnly Cookies

One of the bigger issues is that the client is in full control of the cookie. In fact, JavaScript can set and read cookies just with
document.cookie
So if I sent you a link to a web page and that link contained JavaScript with which you would automatically send me the content of document.cookie, I would get a hold of your session. Luckily there is a simple solution to that, just add “HttpOnly” to your cookie and just like that, the browser and therefore JavaScript can no longer access that specific cookie.
So if the above cookie with your user session of 3kjwdhf38wh324e98uz was flagged as HttpOnly, your browser could not accidentally send it to another page. Accidentally could also mean, being tricked by an attacker into sending it somewhere. Even if your browser wanted to, it just couldn’t do it. That’s a good thing!

Secure cookies are served via HTTPS

If your website was served over HTTPS – which it should be! – there is no reason, why cookies should be sendable via HTTP. But by default that could happen, if you implemented http links in your website. Be it another site or just an image that you referenced with a static link and you missed the s in the protocol, like this:
<img src="http://www.christianjens.com/someImage.png">
Your cookie would be send in the HTTP Request Header as well and a potential attacker could read that traffic and get a hold of your cookie. Again, there is a very simple fix, in fact, it’s just another flag, called secure. Just add that to your cookie declaration and the cookie will only be sent via secure connections. Of course that is only possible, if your site is served via HTTPS, so first go ahead and implement HTTPS, then add secure cookies!

Don’t be afraid of secure cookies

With these two configurations, you just made your cookies a lot more secure. If you now also implemented a path for which they are valid and a validity time frame, you’d be serving secure cookies all the way and we could all take advantage of the comfort cookies provide but we must no longer be afraid of being them.

Let others know if you liked it