Introduction to cookies
- Cookies and security
- How cookies work
- Sending cookies to the server
- Cookie limitations
- Some further details on cookies
- Manage cookies
So what are these strange sweet things that you have surely been offered before by a website
Most of the time, when a web server offers you a cookie, users ignore this by clicking on "OK" without wondering where it has come from. A cookie is in fact a file, that is stored on the user's hard drive which allows the user to distinguish that web page from others. Cookies are mostly used by e-commerce websites where they store the user's preferences (such as options that have been previously selected) so that the user does not have to select them the next time he visits.
Cookies and security
The major problem of cookies is the information they contain. When a user connects to a website that can be personalized, he will be prompted with several questions in order to build a profile, this information is then stored in a cookie. Depending on the website, the manner in which this data is stored could end up being damaging to the user.
In fact, an online sales site could collect information on users' preferences by means of a questionnaire, so that they can suggest items that would be of interest to users.
For example: knowing that a user is male or female, a site can direct the user the appropriate department to save time (and most importantly sell more). If in addition, the user indicates in his profile that he plays tennis, the site will suggest to him a personalized selection of the latest items regarding that subject.
A cookie is therefore a way to create a link between the user's session (browsing certain pages of a website for a certain amount of time) and the data relating to the user.
Ideally, a cookie should contain a random chain (session identification), which is unique and difficult to decipher, and valid only for a given period of time. Only the server should be able to associate the user's preferences with the session identifier. Thus, when the session cookie expires, it becomes useless and should not contain any information relating to the user.
The cookie should never contain direct user information, and its lifespan should be as close as possible to the duration of the user's session.
On the other hand, the data stored in the cookie is sent to the server, to the database where the user entered his data (except the IP address and the browser ID which is automatically transmitted to the server). Thus, the cookie should never contain user information that the user hasn't given himself, nor information on contents of the computer, in other words, the cookie should not collect information from the user's computer.
So, always refuse to give personal information to a website that does not seem legitimate, as it has no right to collect your personal information.
A cookie is not a dangerous file in itself if it is well designed and if the user does not provide personal data.
How cookies work
Cookies are part of the HTTP protocol, which is the protocol used when browsing pages on the web. The HTTP protocol is used to exchange messages between the server and the client using HTTP requests and responses.
HTTP requests and responses contain headers which send specific data in both directions. One of these headers is reserved for writing files to the hard drive: cookies.
Set-Cookie: NAME=VALUE; domain=DOMAIN_NAME; expires=DATE
It is a string of characters beginning with "Set-Cookie:
" and followed by value pairs in the format Name=Value
, separated by semi-colons.
Here is a table of the main value pairs that can be used in a cookie:
|NAME_OF_COOKIE||VALUE||The name and value may not contain the following characters: semi-colon (;), comma (,) or space ( ). Such values can only be added using URL enconding<a/>||This is the only obligatory attribute|
|expires||DATE||Day, DD-MM-YYYY HH:MM:SS GMT||The expires attribute is used to define the date that the cookie should no longer be stored on the hard drive and should no longer be acknowledged by the server.|
|domain||domain_name||xxx.xxx.xxx||The domain name is generally left empty as the name of the server is assigned by default (which is what is usually wanted here). Where indicated, the domain name must contain at least two dots (i.e.: www.commentcamarche.net). A computer from a specific domain can only specify a sub-domain name or its own domain name.|
|path||/directory||/path/||The <i>path value is used to define a folder or file on the server where the cookie is valid, so as to reduce the field of action.|
|secure||none||The secure value is optional. This is used to specify that the cookie will only be sent if the connection is secure (using SSL or HTTPS).|
- A cookie cannot be larger than 4 Kb in size.
- A client cannot store more than 300 cookies on its hard drive.
- A server cannot create more than 20 cookies on the client.
Sending cookies to the server
When a client connects to a site (i.e. a server), domain and path cookies are automatically sent in the headers of the HTTP request The header is in the following format:
Cookie: NAME1=VALUE1; NAME2=VALUE2; ...
A CGI script (or others such as ASP or PHP) then verifies the presence of the cookie:
- by analysing the headers, in the case of a CGI script
- using the Request object, in the case of an ASP script
- using the $NAME1, $NAME2,... variables which are created automatically by the PHP script engine
Cookies are subject to certain restrictions:
- The total number is restricted to 300
- The maximum size is 4kb;
- A maximum of 20 cookies per domain.
Some further details on cookies
- The cookie is not visible until the page has been loaded
- Some browsers do not respond well to cookies
- Microsoft Internet Explorer 4 with Service Pack 1 does not handle cookies correctly, if they have the path value defined.
- Inversely, Netscape Communicator 4.05 and Microsoft Internet Explorer 3.x do not handle cookies correctly if they do not have the path and expiry values defined.
Latest update on November 6, 2012 at 03:10 PM by Jeff.