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 webserver.
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 webserver. 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 webserver 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.
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.
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.