What Is Cookie Poisoning

The term cookie poisoning is used in different contexts to describe attacks that aim to manipulate, intercept, or forge the content of HTTP cookies. Cookie poisoning attacks are different types of attacks that can affect both the client-side application, data transmission, or the web server.

The Many Faces of Cookie Poisoning

The term poisoning in web application security and network security is most often used to describe attacks where the attacker aims to modify stored information, which is later used by a third party with adverse effects. For example, DNS cache poisoning describes attacks, where the content of a DNS cache is modified to direct users of that cache to malicious websites.

However, in the context of cookies, the term poisoning is actually often wrongly used to describe a multitude of different attacks where the content of the cookie is not actually modified. Most of these attacks aim to either access the content of a cookie (cookie hijacking) or forge the content of a cookie from scratch.

Client-Side Cookie Poisoning

The true form of cookie poisoning is rather rare because application programmers nowadays rarely make such basic mistakes. A cookie poisoning attack is initiated by a user who manipulates the content of the cookie for their advantage before the cookie is sent to the web server. All that the user needs to do is to press F12 and use the user’s browser GUI to modify cookies. An advanced user may, of course, also create a suitable HTTP request from scratch according to their needs.

For example, a badly written web application may store the username of the currently logged in user in a cookie. Then, the application may use the content of the cookie to check which user is performing a particular operation. If so, the user may change the content of the cookie to impersonate someone else.

Man-in-the-Middle Cookie Hijacking

The term cookie poisoning is also often used to describe cookie hijacking, which is a form of a man-in-the-middle (MITM) attack. In such a case, the attacker uses some other attack technique to eavesdrop on the communication between the web browser and the web server and gets access to cookie content that is being transmitted.

In a typical MITM attack, the attacker not only listens to communication but may manipulate it. They may either steal sensitive information contained in the transmitted cookie or modify it to their own benefit.

Cookie Hijacking using Buffer Overflow

The content of cookies may also be accessed by unauthorized parties using buffer overflow attacks. If the web server runs software that is vulnerable to buffer overflow attacks, the attacker may read the memory of the server, which often contains most recent cookie information.

However, this type of attack is very rare. Not many applications that are installed on web servers are vulnerable to buffer overflow and even if they are, it has to be a rare coincidence that the attacker manages to find and recognize cookies for a particular site. Note that buffer overflow errors almost never happen in web applications because most popular languages used to create web applications, such as PHP, Java, and JavaScript, are immune to buffer overflows.

Cookies and Sessions

Most attacks that focus on cookies are related to session identifiers, which are most often stored and transmitted using cookies. Session cookies may be the target of different attacks, for example:

• Session hijacking: This type of attack aims to steal the user’s session identifier. The attacker then uses the stolen session identifier to impersonate the user.
• Session fixation: In this type of attack, the attacker tricks the user into using a session identifier that is already known to the attacker. After the user logs in, the attacker can impersonate the user.

Once the attacker gets access to a working user session, they get full access to the victim’s account. Their further actions depend on the type of application. For example, in an online bank, they may have access to some financial operations and extensive personal information, which may be used to escalate the attack further.

Session Forgery

Some sources use the term cookie poisoning to refer to session forgery. Session forgery is possible if the application generates session identifiers in an insecure way and the attacker may calculate or guess how the identifier is formed.

One of the most session forgery cases happened back in 2013 when attackers managed to figure out how Yahoo creates their authentication cookies. Yahoo only admitted to this attack in 2016 and another similar attack happened in 2017. In total, billions of user accounts were accessed without authorization.

Session forgery is possible in the following cases:

• When session identifiers are generated using a predictable algorithm. The simplest case would be a session identifier that is a number, which is incremented by one for every new session. Finding a working session identifier in such a case is trivial.
• When session identifiers are generated on the basis of an insecure random number generator. Finding a working session identifier in such a case is more difficult but still possible.
• When the application does not throttle unsuccessful attempts. In such a case, an attacker may use a simple brute force attack to find a session identifier that works.

To learn more about interesting session forgery attacks based on insecure session identifier generation, read this article.

Cross-site Scripting and Cookie Hijacking

Cross-site Scripting (XSS) attacks are an excellent way to access cookie content, including session identifiers. If the web application is vulnerable to even simple reflected XSS, all that the attacker needs to receive the session identifier is to trick the victim into clicking a supplied link.

Once the victim clicks the link, the content of the session cookie is sent in a request to the attacker’s website. In the simplest case, the attacker only needs to analyze the web server logs to see the session cookie content.

Defending Against Cookie Poisoning

There is no single method to defend against cookie poisoning, simply due to the fact that the term covers such a broad scope of vulnerabilities. The following general security measures help reduce the threat from all kind of cookie-related attacks:

• Never trust the data that is calculated client-side because it may be easily manipulated.
• Use HTTPS communication only, for example, by enforcing HSTS. This greatly reduces the threat of eavesdropping on cookie content.
• Don’t use your own generators to create session identifiers. Trust your web server software to do it for you.
• Regularly scan your web applications using a vulnerability scanner to find and eliminate all security vulnerabilities that may lead to cookie poisoning.

THE AUTHOR

Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
LinkedIn

Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.