Shulou(Shulou.com)06/03 Report--

Type session cookie and persistent cookie of Cookie

The session cookie is a temporary cookie that records the user's settings and preferences when visiting the site. When the user exits the browser, the session cookie is deleted.

Persistent cookie lives longer, it is stored on the user's hard drive, and they still exist when the browser exits or the computer restarts.

The only difference between a session cookie and a persistent cookie is their expiration time.

If the Discard parameter (parameter in cookie version 1) is set, or if the Expires or Max-Age parameter (parameter in cookie version 1) is not set to indicate the expiration time of the extension, this cookie is a session cookie.

How does Cookie work

Cookie can be set up through the server, which is equivalent to a label affixed to the user by the server to track the status of the user.

The cookie information set by the server is returned to the browser through the response header, and the browser saves the cookie information in the response header locally. When the next HTTP request is sent to the server, the saved cookie information is automatically added to the request header (including the cookie set through the [xss_clean] interface).

The following is the response header and request header when logging out of the blog park. There is a Set-Cookie field in the response header and a Cookie field in the request header:

Through the [xss_clean] interface provided by BOM, you can operate on cookie (add, delete, modify) at the front end, which is essentially operating on a string that conforms to certain rules, so that developers can use cookie to store some data locally. Of course, it is recommended to store some non-sensitive information.

Limitations of Cookie and restrictions on the composition of Cookie

There are two main restrictions on Cookie:

Homologous restrictions when accessing cookie

Restrictions on the number and size of Cookie

Homology restriction

Cookie is bound to a specific domain name in nature. When a cookie is created and a request is sent to the domain name that created it, the cookie is included in the request header. This restriction ensures that information stored in cookie can only be accessed by approved domains and not by other domains.

Number and size limit

The number of cookie that can be bound under each domain name is limited, and the number limited by different browsers is different.

The browser limits on the number of cookie under the same domain name are shown in the following table:

browser

Number of cookie that can be bound

IE6

twenty

IE7

fifty

Firefox

fifty

Opera

thirty

Safari

There are no rigid restrictions

Chrome

There are no rigid restrictions

When the cookie is set after the individual domain name limit is exceeded, the browser will clear the previously set cookie.

There are also restrictions on the size of a single cookie in browsers, which are generally limited to 4MB. Size restrictions affect all cookie under a domain name, not each cookie individually.

The composition of Cookie

Name and value name = value: required. Name and value are character sequences that do not include semicolons, commas, equal signs, and spaces unless they are enclosed in double quotes. The Web server can create any name=value association that the browser will send to the web server during subsequent visits to the site.

Domain domain: optional. Indicates for which domain the cookie is valid. This cookie information is included in all requests sent to the domain. This value can contain subdomains (such as www.wrox.com, which means that the cookie information is sent only to that domain name) or not (such as .wrox.com, which is valid for all subdomains of wrox.com). If it is not explicitly specified, the domain is considered to be from the domain of the server that set the cookie.

Path path: optional. This field allows you to assign cookie to specific documents on the server. If the path field is a URL path prefix, you can append a cookie. For example, the path / foo matches / foobar and / foo/bar.html. The path / matches everything in the domain name. The default value is the current directory when Cookie is set.

Failure time expires (max-age field in the new cookie specification): optional. This field specifies a date string that defines the actual lifetime of the cookie. Once this date is reached, the cookie is no longer stored or published, and the cookie is deleted. If the date is set to the previous time, the cookie is deleted immediately.

The date format is GMT format: Wdy, DD-Mon-YYYY HH:MM:SS GMT.

Security flag secure: optional. This field is not in the form of a key-value pair. If you want to specify this field, just add the secure character when setting cookie. When this field is set, the cookie is sent to the server only when a SSL connection is used. For example, if the domain is specified as cookie of www.wrox.com, the cookie can only be sent to https://www.wrox.com after the secure field is established, and the cookie will not be added to the request sent to http://www.wrox.com.

HTTP dedicated HttpOnly: optional. This field can only be set on the server side, indicating whether the cookie can be accessed through JS (the [xss_clean] interface of BOM). By default, the HttpOnly field is empty, indicating that the cookie can be accessed through JS.

According to the specification, developers cannot use JS to modify the HttpOnly field of cookie at the front end, but some browsers do not have this restriction. Take a look at this article: security problems caused by setting the HttpOnly flag in cookie in browsers

For information about how to set this field on the server side, see this article: things about Cookie security settings

Note: the domain, path, expiration time, security flag (secure) and HttpOnly fields are all instructions from the server to the browser on how to store and send cookie. These parameters are not sent as part of the cookie information sent to the server, only the name-value pair (name=value) in the cookie is sent.

In the previous picture, a Set-Cookie in the response header means that the Cookie field in a cookie; request header can contain multiple name-value pairs of cookie instead of just one cookie name-value pair.

[xss_clean] interface of BOM

When used to get cookie, [xss_clean] returns a string of all the cookie available on the current page, a series of name-value pairs separated by semicolons.

For example, I open this page in Chrome: https://segmentfault.com/a/1190000004556040, and enter the following code in the console:

Console.log ([xss_clean])

The following results are output in the console:

PHPSESSID=web2~f57e474e4a8mc396h5du05qsa0;Hm_lvt_e23800c454aa573c0ccb16b52665ac26=1495500966; Hm_lpvt_e23800c454aa573c0ccb16b52665ac26=1495500966;_ga=GA1.2.1399344530.1495500966; _ gid=GA1.2.584865054.1495500966; showRegister2=; showRegister=

There are seven semicolon-separated name-value pairs, indicating that there are seven cookie available (all names and values are URL-encoded, so you must use decodeURIComponent () to decode them. ).

Click the Application option in the developer tool, find the Cookies drop-down menu on the left, and click on the first domain name to see the details of the seven cookie. The details are as follows:

When used to set cookie, [xss_clean] can set a new cookie string that is interpreted and added to the current existing cookie collection. Name-value pairs (name=value) are required (it is best to use encodeURIComponent () to encode name and value), and other fields have been described in the components of cookie.

The cookie set through [xss_clean] does not overwrite the existing cookie unless the name of the set cookie already exists in the existing cookie collection, and the path/domain/secure options must remain the same as the old cookie. Otherwise, instead of modifying the old cookie, a new cookie is added.

Example (using wamp environment):

PHP Code:

HTML Code:

Send request display cookie set cookie

JS Code:

Function myAJAX (url) {var xhr = new XMLHttpRequest (); xhr.onreadystatechange = function () {if (xhr.readyState = 4) {if ((xhr.status > = 200 & & xhr.status < 300) | | xhr.status = = 304) {console.log (xhr.responseText); console.log (xhr.responseXML) } else {console.log (xhr.statusText); console.log (xhr.status);}; xhr.open ("get", url,true); / / true means asynchronous, false means synchronous / / the header information xhr.send (null) is set here;} function init () {var btn = document.getElementById ('btn') Var displayCookie = document.getElementById ('display-cookie'); var resetCookie = document.getElementById (' reset-cookie'); var removeCookie = document.getElementById ('remove-cookie'); btn.addEventListener (' click',function (event) {var url = 'cookie.php'; myAJAX (url);}, false); displayCookie.addEventListener (' click',function (event) {console.log ([xss_clean])) }, false); resetCookie.addEventListener ('click',function (event) {[xss_clean] = "abc=ok;path=/"}, false);} init ()

The first time you open the page, click the display cookie button, there is no output on the console, and the cookie option in the Application tab of the Google developer tool is empty.

Click the send request button to view the header information in the Network tab:

View the cookie in the cookies option in the Application tab:

Now click the Show cookie button:

Only name-value pairs are displayed, and no information is displayed for other fields of the cookie.

Next, click the set cookie button, reset the cookie, and then click the Show cookie button:

The value of the cookie is reset to ok.

Let's click the send request button again to see the header information of this request:

The Cookie field in the request header is the cookie information sent by the browser to the server, and the value of cookie was previously set to ok. The Set-Cookie field in the response header is the cookie information returned by the server to the browser (in fact, the value of cookie is set to test again). (I'm just describing this phenomenon. I don't know if I understand it correctly. ).

There is no direct way to delete an existing cookie. Therefore, you need to set the original cookie again with the same path (path), domain (domain), and security option (secure), and set the expiration time to the past time.

The cookie set through [xss_clean] is also added to the request header by the browser.

For example, set cookie with [xss_clean]:

[xss_clean] = encodeURIComponent ("username") + "=" + encodeURIComponent ("jack") + "; domain=.wrox.com; path=/"; child cookie

A sub-cookie is a smaller piece of data stored in a single cookie. That is, cookie values are used to store multiple name-value pairs.

The format of a seed cookie:

Name=name1=value1&name2=value2&name3=value3&name4=value4

It's essentially a string operation.

Cookie in CORS

(excerpt from teacher Ruan Yifeng's article: detailed explanation of cross-domain resource sharing CORS)

CORS requests do not send Cookie and HTTP authentication information by default. If you want to send Cookie to the server, on the one hand, if you want the server to agree, specify the Access-Control-Allow-Credentials field as true. On the other hand, the developer must open the withCredentials property of the XMLHttpRequest object in the AJAX request. Otherwise, even if the server agrees to send Cookie, the browser will not send it. Alternatively, the server requires that the Cookie be set, and the browser will not handle it.

However, if you omit the withCredentials setting, some browsers will still send Cookie together. At this point, you can explicitly close withCredentials.

It is important to note that if you want to send a Cookie,Access-Control-Allow-Origin, you cannot set it to an asterisk, and you must specify a clear domain name that is consistent with the requested web page. At the same time, Cookie still follows the same origin policy. Only the Cookie set with the server domain name will be uploaded, the Cookie of other domain names will not be uploaded, and the [xss_clean] in the (cross-source) original web page code cannot read the Cookie under the server domain name.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.