This page has been robot translated, sorry for typos if any. Original content here.

Why is a cookie needed?

The fact is that the HTTP protocol is one-time, so to speak. Those. every time you go to the page, the user starts over again, whatever he enters, and what changes he doesn’t. Cookie helps create the illusion that the user is remembered on the site. The user does not need to enter the same information a hundred times from page to page, and even from session to session, it is stored on his disk. Convenience can also be attributed to the fact that the user can always change this information on his disk on the fly. A variety of other data can also be stored in cookies. For example, the number of visits to a page, the time of visits. Using a cookie is not difficult to make a small organizer or basket in a virtual store.

Many people do not like cookies because of its insecurity. Many analysts say that this is not a problem, and nothing bad can be done with this technology. I deeply disagree with this, if someone can read the information from the cookie file (s), then this is already unsafe. I will give purely theoretical examples, which, if desired, are not difficult to translate into reality.
1. Suppose a user logs on to an email site, fills out a login form and password that were recorded in a cookie, even through the Secure Socket Level. The cracker wrote an email to the user in HTML format with cookie reading options with passwords. After reading the cookie, the HTML file or asks the user for permission to send information to the cracker, where the user can be deceived by a false inscription a la "Errors in Javascript scripts!". Even a fairly experienced user will click OK without hesitation, after which login and password will be sent to the cracker. Or the cracker can add a 0 frame, which will temporarily contain information from the cookie, which, when responding to the message, will be inserted at the end of the message. All this is easy to do using FORM and Javascript.
2. An example of a virtual store. Let's say we have a hypothetical shop When making purchases in this store, the user stores information in a cookie. In parallel or before entering the store, the user visited the hacker’s hypothetical page, where the cookie settings of the virtual store were changed. An attacker can change the number of purchases, name, address, and everything that is stored in this cookie. I think you would not like it if you added a couple of monitors to your purchases or took your purchases to the wrong user. To do this is quite simple if you have a page in the domain of the store of the second or third level.

So, for the user, the cookie technology consists of several files in the% WINDOWS% \ Cookies folder (by default in Internet Explorer), or just one cookie.txt file (if it is Netscape Navigator and other browsers). Sites periodically add information to cookies and take it away. Naturally, cookie specifications provide some security features.

- Total Cookies can be no more than 300.
- Each cookie cannot be more than 4kb.
- From one second-level domain (plus sublevels) no more than 20 cookies can be received.
- Information from a cookie of one second-level domain (plus sublevels) cannot be read by other domains.
- If the document is cached, then cookie information is not cached.
- Information can be transmitted to / from a cookie using the SSL protocol.
- If the limit is exhausted, the first entries are deleted. If the cookie gets larger than 4kb, the first bytes are cut out.

In order to control the writing and reading of cookies, you can use special utilities, but this function is available in almost all Firewalls, for example, Agnitum Outpost, and in A4Proxy you can disable all cookies with two clicks of the mouse.