What Is Cookie Poisoning?

Before we dive in, let’s quickly clear up the terminology. In a narrow sense, cookie poisoning refers to attacks that directly modify existing cookie values. Cookies are simply text values stored in the user’s browser, so without additional safeguards, you can easily change them manually or via the document.cookie property in JavaScript. Fortunately, such trivial attacks are rarely possible in modern web development where session management and other operations that involve cookies are usually done at the framework level.

More broadly, the term “cookie poisoning” is often applied to all cookie-related attacks, even ones that, strictly speaking, don’t involve tampering with the cookies themselves. For example, a vulnerable web application might allow a malicious user to discover cookie values or set new cookies to perform a variety of attacks.

Client-Side Cookie Tampering

If you open the developer tools panel in your web browser, you can view and manually modify cookies that are currently set. A vulnerable website or web application might store sensitive state information directly in cookies, for example, a flag to allow admin access. In that case, manually changing cookie names and values in the browser and reloading the page may be enough to gain elevated privileges. In the age of web frameworks, it would be hard to find a production site or application where cookies are manually coded in such a vulnerable way, but theoretically it’s possible.

More usefully for attackers, JavaScript provides the document.cookie property for manipulating cookies from scripts. If a sensitive cookie, such as the session cookie, does not have the additional httpOnly flag, it can be read and modified by malicious scripts following a successful cross-site scripting (XSS) attack. 

Cookie-Based Session Attacks

In its broader sense, cookie poisoning can mean any kind of cookie manipulation, usually targeting session cookies. HTTP is a stateless protocol, so applications use cookies to persist session information and other data on the user’s computer. The session identifier is the most valuable piece of data stored in application cookies, as it opens the way to session hijacking and related attacks.

All cookie-based attacks against user sessions have the same basic aim: to fool the web server into thinking that the attacker is the legitimate user. Here is a quick rundown:

• Session hijacking: Also called cookie hijacking or side-jacking, this is an attack where a user session is taken over by an attacker while the user is logged in to a particular site. The attack relies on the attacker’s knowledge of the current session cookie.
• Session spoofing: Similar to session hijacking but performed when the user is not logged in. Attackers use stolen or forged session tokens to initiate a new session and impersonate the legitimate user with no user interaction required.
• Session fixation: The attacker supplies the session identifier (for example, in a phishing email) and tricks the user into logging in to a vulnerable site using this identifier. If the site allows this, the attacker can then hijack the user session using the known identifier.

Regardless of the method used, a successful session takeover can have disastrous consequences. Depending on the targeted site or application, attackers may be able to steal confidential user information, such as login credentials or personal information, or perform undesirable operations, such as transferring funds or adding a new user account for future access.

Preventing Cookie Poisoning Attacks

As with so many security vulnerabilities, the common denominator of most cookie-related attacks is insufficient input validation and trusting user-controlled data in HTTP requests. Proper cookie hygiene is a fundamental best practice in web application security and there are a number of security measures that can minimize the risk of cookie poisoning attacks:

• Use the right cookie flags and attributes: There are several ways to make cookies less accessible to attackers. By setting the httpOnly flag, you can make a cookie inaccessible to scripts. This is recommended especially for session cookies, as is setting the secure flag to ensure that the cookie is only sent over HTTPS. Carefully selecting values for the domain attribute can also minimize cookie abuse – see our cookie security white paper for more information.
• Use unique and secure session cookies: Session identifiers should be inaccessible to attackers and randomly generated so they are impossible to guess or brute-force. They should also be unusable after the session is closed. See our article on cross-site cookie manipulation for practical examples of attacks against session identifiers in PHP.
• Use each cookie for a single task: It can be tempting to employ multi-purpose cookies, but this complicates workflows and can open up security risks. Session cookies, in particular, should never be used as anti-CSRF tokens or password reset tokens.
• Use proper session management: Cookie security is especially important for session management, as one mistake can open the door to attacks. The first step to following best practices and avoiding simple mistakes is using built-in session management features from a trusted and mature framework rather than reinventing the wheel (and then having to maintain it). See our article to learn why web framework choice matters for security.

Invicti can detect many cookie-related issues to help you secure your web applications. These include general warnings about user-controllable cookies but also more specific recommendations related to the httpOnly and secure flags. In addition, the Cookies node in the Invicti user interface provides a convenient, centralized view of all the cookies found in your application.