Cookies… These small pieces of information are always with us. Since the GDPR was kicked off in Europe, we are flooded by pop-ups asking if we accept “cookies”. Honestly, most people don’t take time to read the warning and just accept the default settings.

If cookies are useful for a website owner to track which actions were previously performed by the visitor (like the page's configuration: language selection, colors, etc…), cookies are also very interesting to maintain sessions, they are called “session cookies” and allow users to be tracked within a website so any action the visitor does is remembered from page to page. Think about an e-commerce website where visitors are browsing between articles, filling up their basket and, finally, check-out.

Cookies are also useful to keep a session “open” to a website and to prevent the visitor to always authenticate again when (s)he’s back. Think about the small option “Stay connected” that you see on login pages. Those are called “Persistent cookies” and help websites to remember your information and settings when you visit them in the future.

From a web developer’s perspective, the way sessions are implemented is critical and must be properly addressed. The session management implementation describes how the session information will be exchanged between the browser and the server. One of the available techniques is to use a cookie and it must be properly implemented. Besides the fact that it must be protected (created with the right flags - Secure & HTTPOnly). It must have an expiration time and, when the user closes his/her session, the cookie must be removed and the session destroyed on the server.

So many times, I’ve seen improper session handling implemented in websites. The user logs off but the session is not really closed on the server-side and/or the cookie remains valid. If an attacker is able to put his hands on the browser and access cookies, it’s easy to load this cookie into another browser and… reactivate the session. This technique is called “session impersonation” or “session hijacking”. And, if the cookie is used to hold a session to an administrative interface, it could have a very bad impact!

For a while, we’ve seen markets on the dark web that… are selling cookies! Forget about passwords or credentials, you just need a cookie to “replay the session” and open doors to many websites! Recently, Electronic Arts suffered from an attack that involved a Slack cookie sold on a black market platform[1]. How suck cookies are collected? The primary source is via botnets that infect computers and crawl sensitive data. For example, the Trickbot trojan has, for a while, a cookie stealing module available[2].

How to protect against this type of attack? From a user’s point of view, cookies are a gold mine and must be protected. They are stored in your browser environment. The best way to protect you is to keep your computer patched! It could also be a good idea to use the "incognito" feature of your browser to avoid storing sensitive information in the browser config.

From a developer’s point of view, be sure to properly handle the sessions. When a user logs off, clean up everything. A good idea is to add more details in the session ID your store in a cookie, add the visitor’s IP address, more fingerprints to detect if a session has been hijacked.

Yes, credentials remain interesting data for attackers but cookies too! Keep them safe!

[1] https://www.vice.com/en/article/7kvkqb/how-ea-games-was-hacked-slack
[2] https://www.bleepingcomputer.com/news/security/trickbot-trojan-now-has-a-separate-cookie-stealing-module/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key