DOM-Based Cookie Manipulation

DOM-based cookie manipulation is a type of cyber attack in which hackers use JavaScript code to mess with the Document Object Model (DOM) (which is the way of your browser so that they can organize webpages) to change or steal cookies.

Cookies are small files your browser which essentially stores to remember things such as your login information, shopping cart, or website preferences, so user don't need to re-enter them each time you visit a same website again. The DOM (Document Object Model) is similar to a blueprint your browser uses to construct and render webpages, arranging everything from text to buttons. Hackers utilize JavaScript—a programming language which allows websites to become interactive—to infiltrate this blueprint and tamper with your cookies, pilfering them or modifying them to deceive websites into believing that the hacker is you.

For example, In 2024, hackers exploited DOM-based cookie manipulation on a gaming website and stole 3,000 Steam cookies through an abusive ad. This allowed them to log in to users' accounts, plunder game items, and sell them for thousands of dollars.

Understanding Firefox's Cookie Management

While cookies are technically DOM nodes, accessing them through the DOM would be rather inconvenient. Fortunately, there is an API provided by nsICookieManager which returns a reference to nsICookieStorage, an interface that exposes a number of convenient methods for managing cookies. The following code demonstrates how to use this API to delete a cookie.

Note that while deleting a cookie may seem like an effective way to block cross-site tracking, in reality, the deleted cookie will simply be replaced with a brand new one. Using this API, cookies are deleted via two different methods. The first method, deleteTopCookie, delete the cookie in question from the memory of the user's browser. The second method, deleteContainerCookie, delete a cookie from the specified storage object. For example, this code would be used to delete an Access Token cookie from storage.

One caveat about deleting cookies through the DOM is that cookies stored in memory persist until deleted manually. For this reason, deleting a cookie does not actually prevent it from being used on subsequent visits. This makes it imperative that users are careful not to leave any cookies lying around in plain text or HTML form fields after they have been deleted.

In addition to being able to edit or delete cookies through the DOM, it is possible to set new values for cookies. This can be accomplished by creating a new cookie, setting its attributes, and then storing it with the Add() method of nsICookieStorage. For example, this code sets a cookie named “test cookie”. Note that the value of a cookie should be treated just like any other HTTP header. It can be manipulated via JavaScript, sent via AJAX requests, and so on.

How it Works

Attackers follow a simple but good plan to mess with your cookies using DOM-based cookie manipulation

Step 1: Inject Harmful Code

Hackers use JavaScript—a tool that makes websites interactive—onto a webpage you visit. This bad code is like a hidden trap, waiting to start when you load the page. They use malicious links like A fake “Win a Free iPhone” link or Malicious Ads

Step 2: Mess with the DOM

After that when javascript code is running that bad code might rewrite your cookie to trick a website into thinking a hacker is you, or it might send your cookie to the hacker’s secret server.

Step 3: Steal or Use the Cookie

With your cookie in hand, hackers can do all sorts of trouble, like:

• Log into your accounts (e.g., Gmail, Amazon, bank).
• Steal your info (e.g., credit card numbers, address).
• Trick websites into sending money or data to the hacker.

What is the Impact of a DOM-Based Cookie Manipulation Attack?

The potential impact of this vulnerability depends on the role that the cookie plays within the website

• If the cookie controls what part of the website you see (like a demo vs. full version), the attacker can change settings and make you do things you didn’t intend to.
• If the cookie keeps track of your login session, the attacker can set a fake login token and then hijack your session. This means they can pretend to be you and access your account.
• If the cookie works across different sites under the same company, the hacker’s trick could affect multiple websites, not just one.

A DOM-based cookie manipulation attack allows hackers to mess with your session, control your actions, or even steal your account. Websites need to secure cookies properly to prevent hackers from tampering with them.

How to prevent DOM-Based Cookie Manipulation

• It is important to note that the browser does not automatically delete cookies that have been set with the Add() method. If a user deletes their cookie with the DeleteTopCookie() method of nsICookieManager, the browser will simply delete the corresponding storage object. 
• Similarly, if a user deletes a cookie from within JavaScript, they will also need to clear it from storage (e.g., by calling DeleteContainerCookie().
• Be careful not to leave HTML form fields with cookies in them after form submission. 
• Cookies stored there can only be deleted through JavaScript. If a user's browser supports “cookies”, these fields should be protected against editing via JavaScript. 
• Cookies with the HttpOnly attribute are inaccessible from JavaScript. 
• Thus, it is not possible to manipulate cookies like normal DOM nodes. 
• This can prevent some attacks like cross-site scripting (XSS). 
• For example, cookie-based XSS attacks almost always require JavaScript in order to set a cookie and then read the value of that cookie via the window. name. Without HttpOnly, these cookies could be used in cross-site request forgery (CSRF) attacks as well.
• Although HttpOnly cookies offer more protection from XSS, there is one exception. An attacker with access to the value of a cookie stored in storage via CORS can still perform cross-site scripting (XSS) attacks using it.

Key Points

• For these reasons, this technique should not be considered an effective cross-site tracking blocker. Setting cookies is quite easy, especially when compared to the difficulty of storing them.
• Some browsers have implemented a database storage mechanism that helps mitigate the issues resulting from random cookie deletion. 
• For example, Firefox includes a “secure cookie” feature that encrypts cookies using a user-provided password and stores them in an encrypted SQLite database. Chrome has chosen not to include this feature at least initially and treats unencrypted cookies as HTTP headers just like any other browser.
• Cookie injection is a class of attack which occurs when a malicious script can modify or overwrite HTTP headers transmitted during client-server communication (Wikipedia: HTTP header injection).

Also Read:

• DOM-based Cross-Site Scripting Attack in Depth
• What is Cross Site Scripting (XSS) ?
• Cross Site Scripting (XSS) Prevention Techniques

Conclusion

This technique falls short of being an effective cross-site tracking blocker because it does not take into account a large number of mechanisms available for setting cookies. Currently, there are few extensions that block cross-site tracking by deleting cookies or clearing the browser's local storage. Blocking third-party cookies is usually considered a good practice, as it theoretically prevents services from measuring the user's web usage in order to provide more targeted advertisements. As a result, there are many extensions that enable users to block third-party cookies. Some of these extensions do this by deleting all third-party cookies.