Cookie poisoning

What is cookie poisoning?

In a cookie poisoning attack, the attacker manipulates the content of HTTP cookies before they are delivered from the user’s browser to a web application. Attackers can precede cookie poisoning with cookie hijacking, which lets them gain access to cookie content before tampering with it, but this is not always necessary.

Cookie poisoning vs. cookie hijacking

Cookie poisoning and cookie hijacking are two different types of attacks. The term poisoning in cybersecurity is used to describe cyberattacks, where a malicious hacker injects malicious content into data while it is being transmitted. Hijacking, on the other hand, is used to describe attacks where malicious hackers attempt to access (read) the data being transmitted.

• The aim of a cookie hijacking attack is to gain access to sensitive information stored in the cookies. This information can be used later in other attacks.
• The aim of a cookie poisoning attack is cookie manipulation. The attacker attempts to change the content of a cookie before it is received by the web application.

Note that many resources on the web incorrectly use the term cookie poisoning for all types of cookie-related attacks, including session hijacking, session fixation, or even brute-force session prediction.

Cookie poisoning in session attacks

Cookies are the most common mechanism used to transmit user session tokens. However, session cookie poisoning makes little sense because manipulating a session ID does not benefit the attacker in any way.

There are three types of attacks related to sessions:

• Session hijacking is all about getting an existing session ID from a logged-in user. If session management is performed using cookies, attackers use cookie hijacking techniques to gain unauthorized access to session data.
• Session fixation happens when a victim is tricked into logging in with a session ID known to the attacker, with the identifier being generated either by the attacker or the web application. This allows the attacker to take over the user’s session later. No cookie poisoning or hijacking is needed in this case because the session ID is generated by the attacker, delivered to the user using social engineering techniques, and then stored in a session cookie.
• Session prediction exploits weaknesses in the way session IDs are generated for a particular site. If the process is not sufficiently random and the attacker figures out the algorithm, they can generate valid session IDs. If session identifiers are short, attackers could even use brute force attacks to guess valid identifiers for authentication. You could, theoretically, use cookie poisoning to replace an existing session ID, but it’s much simpler to just start a new session with a predicted ID.

How does cookie poisoning work?

There are two main approaches to cookie poisoning: client-side and during transmission. Server-side cookie poisoning is also theoretically possible, but if an attacker is able to manipulate cookies directly on the web server, that will usually mean they have exploited a serious vulnerability such as remote code execution and can do much more dangerous things than just tamper with cookies.

Client-side cookie poisoning

The client-side form of cookie poisoning is rarely possible nowadays because application programmers seldom make the basic mistakes that would allow it. This version of the attack may be initiated by the user to, for example, attempt spoofing or privilege escalation (trying to access another user’s account). In the simplest case, a malicious user could press F12 in the browser window and use the built-in developer tools to modify cookies. A more 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 current user’s identity in a cookie and then rely only on the content of that cookie to check which user is performing a particular operation. If the application performs no other checks, manually changing the cookie content may be enough to impersonate another user and gain access to that user’s account. Similarly, if a web application relies only on cookie content to allow or disallow certain user actions, a similar privilege escalation attack could be performed by modifying unprotected information about user privileges stored in the cookie.

Man-in-the-middle cookie poisoning

Cookie poisoning based on a man-in-the-middle attack first requires cookie hijacking. In this case, the attacker accesses, reads, and then modifies cookie content. In the simplest scenario with unencrypted traffic, you only need a simple sniffer working in the same local network as the client to monitor network traffic for user connections and perform packet sniffing. This is especially common for public Wi-Fi networks.

If a website or web application uses encrypted connections exclusively, simple cookie sniffing won’t be effective, but there are other tricks that may be attempted. Some examples include:

• SSL stripping – the attacker tricks the web application into dropping an HTTPS connection and using the insecure HTTP protocol instead, making packet sniffing possible.
• SSL hijacking – the attacker generates a fake SSL certificate for the web application and the victim connects to a cloned or proxy application controlled by the attacker without any certificate warnings.
• DNS cache poisoning – the attacker tricks the victim’s DNS cache into storing manipulated domain information and the victim’s browser is directed to a cloned or proxy application controlled by the attacker.

After successful sniffing, the attacker may inject the local network with packets containing poisoned cookies. Additionally, the attacker may perform a DoS/DDoS attack against the original sender to make sure that the original cookie is delayed long enough for the web application to receive the poisoned content before the legitimate content.

Poisoning cookies is trivial if the user can be directed to an attacker-controlled clone of the web application which then acts as a proxy. The attacker simply needs to change the cookie content sent from the user’s computer to the proxy before the proxy sends it on to the web application.

How to detect cookie poisoning vulnerabilities?

Vulnerabilities resulting from cookie poisoning on the client side are business logic vulnerabilities, so they cannot be detected using automatic methods but only through manual penetration testing. This also means that a web application firewall (WAF) is usually not effective for even temporarily mitigating cookie poisoning attacks.

Cookie poisoning attacks based on MITM target either the connection between the user and web application or the user’s computer, but not the web application itself. The only way to detect such attacks is to carefully monitor network connections and users’ computers for evidence of any tampering.

Note that while security vulnerabilities such as cross-site scripting (XSS) and buffer overflows may allow cookie hijacking, they are not useful for cookie poisoning. This is because both these techniques only allow an attacker to read cookie content, not modify it.

How to prevent cookie poisoning attacks?

To help prevent cookie poisoning attacks, follow these recommendations for security measures:

• As a web application developer or web server administrator, enforce SSL/TLS (HTTPS) for all your pages. For example, use HTTP Strict Transport Security (HSTS) and set security flags for cookies (Secure, HttpOnly).

• When designing your web application, make sure that content exchanged through cookies cannot be easily manipulated by the sender.
• To protect users from attacks aimed directly at their computers and connections, promote the use of VPNs, especially for insecure connections, such as public Wi-Fi.

Frequently asked questions

Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler