Margo Consultants participated in Devoxx France 2018 , the conference for Passionate Developers organized from April 18 to 20, 2018 in Paris. Discover below a first report dedicated to the conference on HTTP cookies that was hosted on Thursday, April 19 by Hubert Sablonnière .

Lou Montulli , co-founder of Netscape and creator of the Lynx Text Web Browser, is an American computer scientist behind the Blink tag and the first Internet Live Cam. He is also known to be the inventor of the famous HTTP Cookies.

Image by Peter Adams Photography

Cookies, not to be confused with server sessions, are stored as small files by the browser and contain information sent by the server.

Cookies can therefore be seen as a communication protocol between the server and the web browser, which defines a particular format for the exchange of data between these two parties.

The following illustration is used to better visualize the operation of Cookies:

But what does a cookie contain?

A Cookie contains all the information that the website needs to map and improve the user experience.

How does this translate technically?

How does a website recognize cookies?

A website can write Cookies via the browser, but how does it find Cookies it has already produced? And above all, how does he prevent other sites from accessing his Cookies?

Cookies can only be accessed via specific rules related to URLs.

Set-Cookie: name=Cookie; Domain=cookies.rocks

Set-Cookie: name=Blue Cookie; Domain=blue.cookies.rocks

Set-Cookie: name=Big Blue Cookie; Domain=big.blue.cookies.rocks

Each of these cookies will only be valid and visible for those areas that correspond hierarchically.

Thus, in this example, “Big Blue Cookies” and “Blue Cookies” will be sent during a request to “blue.cookies.rocks” while “Cookie” will not be sent.

The subdomain cookies are sent during the request to the parent domain.

What about cookies with a .com domain?

It is forbidden to create Cookies with a .com domain. For obvious security reasons, there is a whole list of banned public domains.

The complete list is available here: https://publicsuffix.org/

Browsers all rely on this list to be able to prohibit the creation of Cookies on a public domain.

Protocols

Today, more and more websites are using the HTTPS protocol. This protocol makes it possible to encrypt requests between a user and a website, which enhances security, especially against man-in-the-middle type attacks.

It is therefore possible to manage Cookies only for HTTPS via the “Secure” flag.

Set-Cookie: name=value; Secure

Thus, a request sent to the server via the HTTP protocol will not send Secure type cookies.

It is also possible to force a browser to communicate with an HTTPS server via the HSTS header.

Strict-Transport-Security: max-age=86400; includeSubDomains

Thus, if there are links in the page that are not secure, the browser will replace these links with secure links.

Same Origin Policy

The Same Origin Policy prevents a website from interacting with cookies from another site.

For example, let’s imagine for one moment that thievery.com can interoperate with mabanque.fr. It would be terrible. To avoid this, the Same Origin Policy requires websites to communicate only with themselves.

The Same Origin Policy was introduced in 1995, while the Cookies date back to 1994. Their mode of operation differs on a small and important detail: The Same Origin Policy is based on protocol, domain and port match. Cookies them, only consider the domain.

For example, if an HTTP Web site shares the same domain as another HTTPS Web site, the first one can change the Cookies of the second one. This technique is used during a Man In The Middle attack.

Cookies hijacking

Imagine that a user visits mabanque.fr in HTTPS to consult his accounts and that, in parallel, he decides to be entertained with videos-de-chats.fr in HTTP. If videos-de-chats.fr makes a request in HTTP to mabanque.fr, this request will be able to use or modify Cookies of mabanque.fr, even those in HTTPS.

Of course, if the website mabanque.fr has the HSTS, it protects its users against this kind of attack.

Boosting Cookies

A new feature has emerged, to enhance security around Cookies and prevent this type of attack.

Cookies with __Secure- or __Host- prefixes force the use of the Secure flag and force a change of policy at the browser level.

The reading and the modification are only accessible via the HTTPS protocol.

For the moment, only the latest versions of Chrome and Firefox support Prefix Cookies.

Conclusion

Cookies are often used to store user data or even information related to the authentication of the latter.

You have to be aware of the dangers and the risks involved, the consequences can be terrible.

It is not necessary to forgo the Cookies, they are valuable allies, because there are ways to secure their use.

Sources:

https://github.com/hsablonniere/talk-back-to-basics-cookies/blob/master/src/slide-deck.adoc

https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/