Cookie (computing)

Purpose

Cookies are commonly used by application servers to differentiate users and to act differently depending on them. Cookies were invented to be used in a virtual shopping basket, which acts as a virtual device in which the user "places" the items you want to purchase, so that users can browse the site where the items for sale are displayed and add and remove them from the shopping cart at any time. Cookies allow the content of the shopping cart to depend on the actions of the user.

One use of cookies is to identify yourself to a website. Users typically identify themselves by entering their credentials on a validation page; cookies allow the server to know that the user is already validated, and therefore may be allowed to access services or perform operations that are restricted to unidentified users.

Other websites use cookies to customize their appearance based on user preferences. Sites that require identification often offer this feature, although it is present on others that do not. Personalization includes both presentation and functionality. For example, Wikipedia pages allow logged in users to choose a presentation style to their liking; Google's search engine allows users (even unregistered ones) to decide how many search results they want to see on each page.

Cookies are also used to track users throughout a website. Third-party cookies and web server errors explained below also enable cross-site tracking. Site tracking is typically done with the intent of keeping usage statistics, while cross site tracking is typically aimed at creating anonymous user profiles by advertising companies, which will then be used to target campaigns. advertising (decide what type of advertising to use) based on user profiles.

Realization

A possible interaction between a web browser and a server, in which the server sends r and the browser returns it when requesting another page.

Technically, cookies are arbitrary pieces of data defined by the web server and sent to the browser. The browser returns them to the server unchanged, thus reflecting a state (previous event memory) in HTTP transactions, which would otherwise be independent of that state.

Without cookies, each request for a web page or a component of a web page would be an isolated event, unrelated to other requests for other pages on the same site. But by returning a cookie to the web server, the browser provides the server with a means to match the current page request with previous page requests. In addition to being set by a web server, cookies can also be set by a script in a language such as JavaScript, if this is supported and enabled in the web browser.

The cookie specifications suggest that browsers must support a minimum number of cookies or a minimum amount of memory to store them. Specifically, a browser is expected to be capable of storing at least 300 cookies of 4 kilobytes each and at least 20 cookies per server or domain.

The server that sets the cookie may specify a deletion date, in which case the cookie will be deleted on that date. A shopping site might want to help potential customers by remembering the things that were in their shopping cart, even if they close the browser without making the purchase and come back later, so they don't have to search for the products again. In that case, the server would create a cookie with a deletion date as desired by the website designer. If no deletion date is defined, the cookie is deleted when the user closes their browser. Therefore, defining a deletion date is one way to make the cookie survive between sessions. For this reason, cookies with a deletion date are called persistent.

Wrong ideas

Since their introduction on the Internet, misconceptions about cookies have circulated. In 2005, Jupiter Research published the results of a study, according to which a significant percentage of interviewees believed some of the following statements:

• The Cookies are similar to worms and viruses that can erase data from users' hard drives.
• The Cookies are a type of spyware because they can read personal information stored on the computer of users.
• The Cookies generate pop-ups.
• The Cookies are used to generate garbage content.
• The Cookies are only used for advertising purposes.

In reality, cookies are only data, not code, so they cannot delete or read information from users' computers. However, cookies allow detecting the pages visited by a user on a given site or set of sites. This information may be collected in a user profile. These profiles are usually anonymous, that is, they do not contain the user's personal information (name, address, etc.). In fact, they cannot contain it unless the user himself has communicated it to one of the sites visited. But while anonymous, these profiles have been the subject of some privacy concerns.

According to the same report, a large percentage of Internet users do not know how to delete cookies.

Browser Settings

Most modern browsers support cookies. However, a user can normally choose whether cookies should be used or not. Here are the most common options:

1. The browser asks the user if each cookie.

The manager of Cookies of Firefox, showing the details of several Cookies by domain

The browser may also include the ability to better specify which cookies have to be accepted and which ones not. Specifically, the user can normally accept one of the following options: reject cookies from certain domains; reject third party cookies (see below); accept cookies as non-persistent (they are deleted when the browser is closed); allow the server to create cookies for a different domain. In addition, browsers may also allow users to view and delete cookies individually.

Most browsers that support JavaScript allow users to see the cookies that are active on a given page by typing javascript:alert("Cookies: " +document.cookie) in the address field.

The P3P specification includes the ability for a server to define a privacy policy that specifies what kind of information it collects and for what purpose. These policies include (among other things) the use of information collected through cookies. According to the P3P specification, a browser can accept or reject cookies by comparing the privacy policy with the user's stored preferences, or prompt the user, offering the privacy policy declared by the server.

Third-party cookies

Cookies have important implications for the privacy and anonymity of web users. Although cookies are only sent to the server that set them or to another server in the same domain, a web page may contain images and other components stored on servers in other domains. The cookies that are created during requests from these components are called third-party cookies or cookies tracking.

Advertising companies use third-party cookies to track users across multiple sites. Specifically, an advertising company can follow a user through all the pages where they have placed advertising images or web bugs. Knowing the pages visited by a user allows these companies to target their advertising according to the user's supposed preferences.

Restrictions

Little by little, browsers themselves have been incorporating configuration options that allow third-party cookies to be blocked.

The ability to profile users has been considered a potential privacy threat, even when tracking is limited to a single domain, but especially across multiple domains using third-party cookies. For this reason, some countries have legislation on cookies.

The United States government defined strict rules for the creation of cookies in 2000, after it became known that the White House Office of National Drug Control was using cookies to track users who, after visiting their anti-drug campaign, visited sites related to the manufacture or use of drugs. In 2002, privacy activist Daniel Brandt found out that the CIA had been setting persistent cookies on computers for ten years. When informed that they were violating policy, the CIA confirmed that these cookies were not intentionally created, and stopped using them. On December 25, 2005, Brandt discovered that the National Security Agency had been creating two persistent cookies on its visitors' computers due to a software update. Upon being informed, the agency immediately disabled cookies.

The 2002 European Union directive on privacy in telecommunications contains rules on the use of cookies. Specifically, in article 5, paragraph 3, it establishes that the storage of data (such as cookies) on a user's computer can only be done if: 1) the user receives information on how that data is used; and 2) the user has the possibility to reject that operation. However, this article also states that storing data that is necessary for technical reasons is allowed as an exception. It was expected that this directive would have started its application since October 2003, but a report from December 2004 says (page 38) that it has not been applied in practice, and that some member countries (Slovakia, Latvia, Greece, Belgium and Luxembourg) have not even transposed it into their legislation. The same report suggests a thorough analysis of the situation in the member states.

Subsequent legislation also requires consumers to be informed that their websites use cookies. For example, the European General Data Protection Regulation (GDPR) of 2016 or the California Consumer Privacy Act (CCPA) of 2018.

In 2020 Google announced that it would not allow the use of third-party cookies in Chrome by 2022. It later deferred the move to mid-2023. Google is promoting the use of the FLoC API as a substitute.

Disadvantages of cookies

In addition to the privacy issues already mentioned, there are other reasons why the use of cookies has received some opposition: they do not always correctly identify users, and they can be used for security attacks.

Misidentification

If more than one browser is used on a computer, each has its own storage of cookies. Therefore, cookies do not identify a person, but a combination of user account, computer and browser. In this way, anyone who uses multiple accounts, multiple computers, or multiple browsers also has multiple cookie sets.

In the same way, cookies do not differentiate between several people who use the same computer or browser, if they do not use different user accounts.

Cookie theft

During normal operation, cookies are sent in both directions between the server (or group of servers in the same domain) and the computer of the user who is browsing. Since cookies can contain sensitive information (username, a token used for authentication, etc.), their values should not be accessible from other computers. However, cookies sent over normal HTTP sessions are visible to all listening users on the network using a packet sniffer. These cookies should therefore not contain sensitive information. This problem can be circumvented by using https, which invokes transport layer security to encrypt the connection.

Cross-site scripting allows the value of cookies to be sent to servers that would not normally receive that information. Modern browsers allow the execution of code segments received from the server. If cookies are accessible at runtime, their value can be communicated in some way to servers that shouldn't be accessing them. The process that allows an unauthorized party to receive a cookie is called cookie theft, and encryption is useless against this type of attack.

This capability is commonly exploited by attackers of sites that allow users to submit HTML content. By inserting a suitable code segment in an HTML submission, an attacker can receive cookies from other users. Knowledge of these cookies can then be exploited by connecting to the sites where the stolen cookies are used, thus being identified as the user whose cookies were stolen. cookies.

Cookie forgery

Although cookies should be stored and sent back to the server unchanged, an attacker could modify the value of cookies before returning them. If, for example, a cookie contains the full value of a user's purchase on a website, changing that value on the server could allow an attacker to underpay for their purchase. The process of modifying the value of cookies is called cookie spoofing and is often done after cookie theft to make a persistent attack.

However, most websites only store in the cookie a session identifier - a unique number used to identify the user's session - and the rest of the information is stored in the own server. In this case, the problem of forging cookies is practically eliminated.

Cookies between sites (cross-site cooking)

Each site should have its own cookies, so that one bad.net site has no chance to modify or set another's cookies site as bueno.net. Browser cross-site cookie vulnerabilities allow malicious sites to break this rule. This is similar to cookie spoofing, but the attacker takes advantage of non-malicious users with vulnerable browsers, rather than attacking the website directly. The goal of these attacks may be to perform session fixation (session theft on a website).

Alternatives to cookies

Some of the operations that can be performed using cookies can also be performed using other mechanisms. However, these alternatives to cookies have their own drawbacks, which end up making cookies the preferred option in practice. Most of the alternatives described below allow user tracking, although admittedly not as reliably. That is why privacy remains an issue, even if the browser rejects cookies and the server does not set them.

IP address

An unreliable technique of tracking users is based on storing the IP address of the computer requesting the pages. This technique has been available since the beginning of the World Wide Web, as it is necessary to download pages that the server that has them knows the IP address of the computer where the browser is running, or of its proxy server if there is one. The server can save this information, regardless of the use or not of cookies.

However, these addresses are usually less reliable than cookies for identifying a user, because computers and proxies may be shared by several users, and the same computer can be assigned different IP addresses in different sessions (typical case in telephone connections, but also through ADSL and other technologies). The reliability of this technique can be increased by using another feature of the HTTP protocol: when a browser requests a page because the user has followed a link, the request that is sent to the server contains the URL of the page where the link was located.. If the server stores those URLs, the path of pages visited by the user can be tracked more precisely. However, these traces are less reliable than those provided by cookies, since several users can access the same page from the same computer, router with NAT or proxy, and then follow different links. Furthermore, this technique only enables tracking, and cannot replace cookies in its other uses.

Tracking of IP addresses may be impossible on some systems that are used precisely to maintain anonymity on the Internet, such as Tor. With such systems, not only can a browser use multiple addresses throughout a session, but multiple users could appear to be using the same IP address, thus making the use of IP addresses an utterly useless technique for user tracking.

URL (query string)

A more precise technique is to embed information in the URL. The query string that is part of the URL is normally used for this purpose, but other parts can be used as well. PHP's session mechanism uses this method if cookies are not enabled.

This method consists of the web server adding query strings to the links of the web page it contains, when serving it to the browser. When the user follows a link, the browser returns the query string appended to the links to the server.

The query strings used in this way are very similar to cookies, with both pieces of information being defined by the server and returned by the browser later. However, there are differences: since a query string is part of a URL, if the URL is reused later, the same piece of information will be sent to the server. If, for example, a user's preferences are encoded in the query string of a URL, and the user sends that URL to another user by some means, those preferences will also be used by that other user.

Furthermore, even if the same user accesses the same page twice, there is no guarantee that the same query string will be used on both. If, for example, the same user arrives at the same page twice, once from another page on the same web server, and once from a browser, the respective query strings will normally be different, while the cookies would have been identical. For more details, see query strings.

Other disadvantages of query strings are related to security: storing in a query string information that identifies a session allows or simplifies session fixation attacks, referrer tracking attacks, and others. vulnerabilities. The transfer of session identifiers in the form of cookies is more secure.

Another disadvantage of query strings has to do with the way the web is designed. URLs should point to resources and be "opaque". See representational state transfer. If you have a URL that includes a query string, it is no longer the actual location of the resource.

HTTP Authentication

For authentication, the HTTP protocol includes mechanisms such as digest access authentication, which allows access to a web page only when the user has provided a correct username and password. Once the credentials have been entered, the browser stores them and uses them to access the following pages, without asking the user for them again. From the user's point of view, the effect is the same as if cookies are used: the username and password are only asked once, and from then on the user gets access to the pages from the server. Internally, the username and password are sent to the server with each browser request. This means that someone listening to this traffic could read this information and store it for later use. The sessions, however, normally expire after a certain period of inactivity, thus being invalidated to, for example, recover the session that the user who was browsing had.

Locally Stored Macromedia Flash Objects

If a browser includes the Macromedia Flash Player plug-in, it can use the local shared objects feature of the browser, much like cookies. Locally stored objects (local stored objects) can be an interesting option for web developers because most Windows users have Flash Player installed, the default maximum object size is 100 kb, and the security controls are different from the user controls for cookies, so that locally stored objects may be enabled when cookies are not.

Client persistence

Some web browsers support a script-based persistence mechanism that allows the page to store information locally for later use. Internet Explorer, for example, supports persistent information in the browser's history, in bookmarks, in an XML store, or directly on a web page saved to disk.

JavaScript window.name Property

If JavaScript is enabled, you can use the window.name property of the window object to store information persistently. This property remains unchanged during the loading of other web pages. This little hack is not very well known, and therefore it has not been considered a security flaw. Also, the use of window.name has compatibility issues with browsers, as some, such as those based on Mozilla of which Mozilla Firefox is an example, do not support persistence with JavaScript using window.name.

Implementation

Creating a cookie

Web page transfer follows HTTP. Despite cookies, browsers request a server page to send them a short text called HTTP. For example, to access the page http://www.w3.org/index.html, browsers connect to the www.w3.org server by sending a request that looks like the following:

The server responds by sending the requested page preceded by a similar text, called an HTTP header. This packet may contain lines asking the browser to save cookies:

The Set-cookie line is only sent if the server wants the browser to save cookies. In effect, it is a request to the browser to save the name=value sequence and send it back on any future server requests. If the browser supports cookies and cookies are allowed, each subsequent page request to the same server will contain the cookie. For example, the browser requests the page http://www.w3.org/spec.html by sending the www.w3.org server a request that looks like the following:

This is a request for another page from the same server, and it differs from the first because it contains the stream that the server had previously sent to the browser. Where, the server knows that this request is related to the previous one. The server responds by sending the requested page, possibly adding other cookies as well.

The cookie value can be changed by the server by sending a new Set-Cookie: name=newvalue line in response to the page request. The browser then replaces the old value with the new one.

The Set-Cookie line is typically not generated by the HTTP server itself, but by a CGI program. The HTTP server only sends the output of the program (a document preceded by the header containing cookies) to the browser.

Cookies can also be set by JavaScript or similar scripts in your browser. In JavaScript, the document.cookie object is used for this purpose. For example, the statement document.cookie = "temperature=20" creates a cookie with name temperature and value 20.

Cookie attributes

Expiration

When cookies have expired, they are not sent to the browser; therefore, the expiration of cookies can be thought of as a time limit in which one of them can be used. The cookie can then be renewed after this limit has passed. Some sites prefer cookies to expire in shorter times for security reasons. Cookies are not sent to the server under these conditions:

• at the end of a user session: for example, when the browser is closed (if this is not persistent)
• A expiration date has been set and this has passed.
• The expiration date is changed to a previous date (by the server)
• this is deleted by user order.

Note: The third condition allows a server to explicitly delete a cookie.

Authentication

Many servers or web pages use cookies to recognize users who have already authenticated themselves or to customize web pages depending on the options a user selects. For example, this can happen when:

• The user writes their name and password, which are sent to the server
• The server checks the information provided, and if it is correct returns a confirmation page with a cookie, thus saving this information on the user's computer.
• When the user visits a page that belongs to the server, it verifies the existence of the Cookies And then check if they Cookies existing are equal to those that have been saved on the server. If there are matches, the server can identify the user who requested the page.

This is one of the most common authentication methods, used by Yahoo!, Wikipedia, or Facebook.

Another use of cookies refers to the tracking of a route (path) that a user takes when browsing through web pages on a server or site. This can also be obtained when using a computer's IP address, although cookies have better accuracy. This can be done as follows:

• If the user visits a website but the request does not contain a cookie, the server assumes that this is the first visit to that page; the server creates a series of random characters, which are then sent as a cookie in addition to the requested page.
• From now on, the cookie is automatically sent to the server by the browser whenever a page has been requested. The server sends a page as always, but the date and time are saved in a visit log with the cookie.

If the log is then read, it is possible to identify when, who, and the sequence in which a user accessed which pages.

Basket

Some web pages, particularly product buying or selling pages, allow users to save items in a "virtual basket" even if they are logged out. A list of these objects can be stored in a cookie. For example, when the user adds an item to his virtual basket, the server adds the name of this object to the cookie. However, this is a very insecure method as the cookie can easily be tampered with by another user. A better way might be to set a "tracking" random and then use it as a reference on the server.