Cookie and Session

Terminologis

Session cookie A session cookie only lasts for the duration of users using the website. A web browser normally deletes session cookies when it quits. A session cookie expires if the user does not access the website for a period of time chosen by the server (idle timeout).
Persistent cookie A persistent cookie will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to server every time the user visits the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason, persistent cookies are also called tracking cookies. 

Secure cookie
A secure cookie is only used when a browser is visiting a server via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server. This makes the cookie less likely to be exposed to cookie theft via eavesdropping.

HttpOnly cookie
The HttpOnly cookie is supported by most modern browsers.On a supported browser, a HttpOnly cookie will only be used when transmitting HTTP (or HTTPS) requests. In addition, the cookie value is not available to client side script (such as Javascript), thereby mitigating the threat of cookie theft via Cross-site scripting.

Third-party cookie
First-party cookies are cookies set with the same domain (or its subdomain) in your browser's address bar. Third-party cookies are cookies being set with different domains than the one shown on the address bar.
For example: Suppose a user visits www.example1.com, which sets a cookie with the domain ad.foxytracking.com. When the user later visits www.example2.com, another cookie is set with the domain ad.foxytracking.com. Eventually, both of these cookies will be sent to the advertiser when loading their ads or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites this advertiser has footprints on.
See Privacy and Third-party cookies below for more. 

Super cookie
A Super cookie is a cookie with a Public Suffix domain, like .com, .co.uk or k12.ca.us.
Most browsers, by default, allow first-party cookies—a cookie with domain to be the same or sub-domain of the requesting host. For example, a user visiting www.example.com can have a cookie set with domain www.example.com or .example.com, but not .com. A super cookie with domain .com would be blocked by browsers; otherwise, a malicious website, like attacker.com, could set a super cookie with domain .com and potentially disrupt or impersonate legitimate user requests to example.com. Unfortunately, the Public Suffix List keeps changing. Older versions of browsers will not have the most up-to-date list, and will therefore be vulnerable to certain super cookies. 

Zombie cookie
Main article: Zombie cookie
A zombie cookie is any cookie that is automatically recreated after a user has deleted it. This is accomplished by a script storing the content of the cookie in some other locations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating the cookie from backup stores when the cookie's absence is detected.

What do Cookies Do?
A cookie is the term given to describe a type of message that is given to a Web browser by a Web server.  The main purpose of a cookie is to identify users and possibly prepare customized Web pages or to save site login information for you.
When you enter a Web site using cookies, you may be asked to fill out a form providing personal information; like your name, e-mail address, and interests. This information is packaged into a cookie and sent to your Web browser, which then stores the information for later use. The next time you go to the same Web site, your browser will send the cookie to the Web server. The message is sent back to the server each time the browser requests a page from the server.
A Web server has no memory so the hosted Web site you are visiting transfers a cookie file of the browser on your computer's hard disk so that the Web site can remember who you are and your preferences. This message exchange allows the Web server to use this information to present you with customized Web pages. So, for example, instead of seeing just a generic welcome page you might see a welcome page with your name on it.

Session management
Cookies may be used to maintain data related to the user during navigation, possibly across multiple visits. Cookies were introduced to provide a way to implement a "shopping cart" (or "shopping basket"),a virtual device into which users can store items they want to purchase as they navigate throughout the site.
Shopping basket applications today usually store the list of basket contents in a database on the server side, rather than storing basket items in the cookie itself. A web server typically sends a cookie containing a unique session identifier. The web browser will send back that session identifier with each subsequent request and shopping basket items are stored associated with a unique session identifier.
Allowing users to log in to a website is a frequent use of cookies. Typically the web server will first send a cookie containing a unique session identifier. Users then submit their credentials and the web application authenticates the session and allows the user access to services.
Personalization Cookies may be used to remember the information about the user who has visited a website in order to show relevant content in the future. For example a web server may send a cookie containing the username last used to log in to a web site so that it may be filled in for future visits.
Many websites use cookies for personalization based on users' preferences. Users select their preferences by entering them in a web form and submitting the form to the server. The server encodes the preferences in a cookie and sends the cookie back to the browser. This way, every time the user accesses a page, the server is also sent the cookie where the preferences are stored, and can personalize the page according to the user preferences. For example, the Wikipedia website allows authenticated users to choose the webpage skin they like best; the Google search engine allows users (even non-registered ones) to decide how many search results per page they want to see.
Tracking Tracking cookies may be used to track internet users' web browsing habits. This can also be done in part by using the IP address of the computer requesting the page or the referrer field of the HTTP request header, but cookies allow for greater precision. This can be demonstrated as follows:

1. If the user requests a page of the site, but the request contains no cookie, the server presumes that this is the first page visited by the user; the server creates a random string and sends it as a cookie back to the browser together with the requested page;
2. From this point on, the cookie will be automatically sent by the browser to the server every time a new page from the site is requested; the server sends the page as usual, but also stores the URL of the requested page, the date/time of the request, and the cookie in a log file.

By looking at the log file, it is then possible to find out which pages the user has visited and in what sequence. 

Setting a cookie
Transfer of Web pages follows the HyperText Transfer Protocol (HTTP). Regardless of cookies, browsers request a page from web servers by sending them a usually short text called HTTP request. For example, to access the page http://www.example.org/index.html, browsers connect to the server www.example.org sending it a request that looks like the following one:

	GET /index.html HTTP/1.1 Host: www.example.org
browser	-------→	server

The server replies by sending the requested page preceded by a similar packet of text, called 'HTTP response'. This packet may contain lines requesting the browser to store cookies:

	HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value Set-Cookie: name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT (content of page)
browser	←-------	server

The server sends lines of Set-Cookie only if the server wishes the browser to store cookies. Set-Cookie is a directive for the browser to store the cookie and send it back in future requests to the server (subject to expiration time or other cookie attributes), if the browser supports cookies and cookies are enabled. For example, the browser requests the page http://www.example.org/spec.html by sending the server www.example.org a request like the following:

	GET /spec.html HTTP/1.1 Host: www.example.org Cookie: name=value; name2=value2 Accept: */*
browser	-------→	server

This is a request for another page from the same server, and differs from the first one above because it contains the string that the server has previously sent to the browser. This way, the server knows that this request is related to the previous one. The server answers by sending the requested page, possibly adding other cookies as well.
The value of a cookie can be modified by the server by sending a new Set-Cookie: name=newvalue line in response of a page request. The browser then replaces the old value with the new one.
The term "cookie crumb" is sometimes used to refer to the name-value pair.This is not the same as breadcrumb web navigation, which is the technique of showing in each page the list of pages the user has previously visited; this technique, however, may be implemented using cookies.
Cookies can also be set by JavaScript or similar scripts running within the browser. In JavaScript, the object document.cookie is used for this purpose. For example, the instruction document.cookie = "temperature=20" creates a cookie of name temperature and value 20.
Cookie attributes Besides the name-value pair, servers can also set these cookie attributes: a cookie domain, a path, expiration time or maximum age, secure flag and httponly flag. Browsers will not send cookie attributes back to the server. They will only send the cookie’s name-value pair. Cookie attributes are used by browsers to determine when to delete a cookie, block a cookie or whether to send a cookie (name-value pair) to the servers.
Domain and Path The cookie domain and path define the scope of the cookie—they tell the browser that cookies should only be sent back to the server for the given domain and path. If not specified, they default to the domain and path of the object that was requested. An example of Set-Cookie directives from a website after a user logged in:

Set-Cookie: LSID=DQAAAK…Eaem_vYg; Domain=docs.foo.com; Path=/accounts; Expires=Wed, 13-Jan-2021 22:23:01 GMT; Secure; HttpOnly Set-Cookie: HSID=AYQEVn….DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13-Jan-2021 22:23:01 GMT; HttpOnly Set-Cookie: SSID=Ap4P….GTEq; Domain=.foo.com; Path=/; Expires=Wed, 13-Jan-2021 22:23:01 GMT; Secure; HttpOnly  ......

The first cookie LSID has default domain docs.foo.com and Path /accounts, which tells the browser to use the cookie only when requesting pages contained in docs.foo.com/accounts. The other 2 cookies HSID and SSID would be sent back by the browser while requesting any subdomain in .foo.com on any path, for example www.foo.com/.
Expires and Max-Age The Expires directive tells the browser when to delete the cookie. It is specified in the form of “Wdy, DD-Mon-YYYY HH:MM:SS GMT”, indicating the exact date/time this cookie will expire. As an alternative to setting cookie expiration as an absolute date/time, RFC 2965 allows the use of the Max-Age attribute to set the cookie’s expiration as an interval of seconds in the future, relative to the time the browser received the cookie. An example of Set-Cookie directives from a website after a user logged in:

Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; expires=Tue, 15-Jan-2013 21:47:38 GMT; path=/; domain=.foo.com; httponly Set-Cookie: made_write_conn=1295214458; path=/; domain=.foo.com Set-Cookie: reg_fb_gate=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.foo.com; httponly  ......

The first cookie lu is set to expire sometime in 15-Jan-2013, it will be used by the client browser until that time. The second cookie made_write_conn does not have an expiration date, making it a session cookie. It will be deleted after the user closes his/her browser. The third cookie reg_fb_gate has its value changed to deleted, with an expiration time in the past. The browser will delete this cookie right away – note that cookie will only be deleted when the domain and path attributes in the Set-Cookie field match the values used when the cookie was created.
Secure and HttpOnly Secure and HttpOnly attributes do not have a value field, the existence of the attribute names serves as indications that the cookie is Secure or HttpOnly.
A Secure attribute tells the browser to only use this cookie via secure/encrypted connections, obviously, web servers should also set this cookie via secure channels, and therefore anyone eavesdropping on your communication would not pick up the cookie.
An HttpOnly attribute tells the browser to only use the cookie for the HTTP protocol. The cookie is not visible to client side scripts, and therefore cannot be stolen via cross-site scripting (a pervasive attack technique). As shown in previous examples, both Facebook and Google use HttpOnly attribute extensively.