Hostonly Cookies and HttpOnly cookies

How do I use cookies?

Usually we have two ways to set or get cookies for the browser, respectively, the Set-cookie header in HTTP Response headers and the cookie header in HTTP Request headers, and assign or value the Document.cookie through JavaScript.

rfc6265 Section 5.2 defines the Set-cookie Header, in addition to the Cookie body must contain, can optionally contain 6 properties path, domain, Max-age, expires, secure, HttpOnly, Between them in English semicolons and spaces ("; ") connection.

The body part of a cookie is a string of Key=value key-value pairs connected by &, similar to a query string in a URL. The following is a standard Set-cookie Header:

-Shrinkage HTMLCode Run code[If the run is ineffective, save the source code as an HTML file]Set-cookie:key=value; Path=path; Domain=domain; Max-age=max-age-in-seconds; Expires=date-in-gmtstring-format; Secure HttpOnly

On the browser side, cookies can also be set via Document.cookie, for example, in the MDC document, where the contents of the cookie must include the body, as well as 5 properties: path, Domain, Max-age, expires, secure. The following is a simple example:

-Shrinkage HTMLCode Run code[If the run is ineffective, save the source code as an HTML file]Document.cookie = "Key=value; Path=path; Domain=domain; Max-age=max-age-in-seconds; Expires=date-in-gmtstring-format; Secure ";

There are two points to note:

• Max-age as a supplement to the expires, there are compatibility issues at this stage (ie low version does not support), so generally not used alone;
• JS in the setting of the cookie and the HTTP method compared, less control of the HttpOnly, because JS can not read and write HttpOnly cookies;

I found in the browser test, if the HttpOnly is not considered, the JS or HTTP settings of the cookie is not different, the cookie is obtained by JS or HTTP content is the same. Therefore, in the subsequent testing of this article, it is not necessary to indicate the way in which cookies are operated.

What is a hostonly Cookie?

rfc6265 Section 5.3 Defines the fields that the browser should include when storing each cookie: name, value, expiry-time, domain, path, creation-time, Last-access-time, Persistent-flag, Host-only-flag, Secure-only-flag and Http-only-flag.

which

• Name, value: specified by the cookie body;
• Expiry-time: Based on expires and max-age in the cookie;
• Domain, path: specified by domain and path in the cookie, respectively;
• Creation-time, Last-access-time: obtained by the browser itself;
• Persistent-flag: Persistent token, false in case of expiry-time unknown, indicates that this is a session cookie;
• Secure-only-flag: True when the cookie contains the secure attribute, indicating that the cookie is only available in an HTTPS environment;
• Http-only-flag: True when the cookie contains the HttpOnly attribute, indicating that the cookie is not allowed to read and write via JS;
• host-only-flag: The domain attribute is not included in the cookie, or the domain property is empty, or the domain property is not legal (not equal to the domain part in the page URL, is not a domain of page domain) is true. At this point, we refer to this cookie as hostonly cookie;

So what happens to Host-only-flag if it's true? There is such a rfc6265 in the house:

Either:the Cookie ' s host-only-flag is true and the canonicalized request-host are identical to the cookie ' s domain.

Or:the Cookie ' s Host-only-flag is false and the canonicalized request-host domain-matches the cookie ' s domain.

To get a cookie, first check the domain match, and then check the matching of path, secure, httponly and other attributes. If Host-only-flag is true, only the current domain name is fully equal to the domain property of the cookie to enter the subsequent process; When Host-only-flag is false, Domain names that conform to the domain rules (domain-matches) can enter a subsequent process.

For example, when Host-only-flag is true, a cookie with the domain property of example.com is only possible when example.com is available, and Host-only-flag is false. The domain property is a example.com cookie, which can be obtained in example.com, www.example.com, sub.example.com, and so on.

Next, let's look at the support for the hostonly cookie, the Host-only-flag attribute of the cookie, for each browser.

Support Level Test

In qgy18.com, set the following hostonly Cookie:

-Shrinkage HTMLCode Run code[If the run is ineffective, save the source code as an HTML file]Name=ququ; Expires=tue, 10-jul-2013 08:30:18 GMT; path=/

Visit www.qgy18.comto obtain a cookie with the following results:

Browser	cookies acquired in www.qgy18.com
Chrome 29.0.1547.3 Dev
Firefox 22.0
Chrome 27.0.1453.116 m
IE 6.0.2900.5512	Name=ququ
IE 10.0.9200.16438	Name=ququ
Opera 12.15 (Presto core, non-webkit)
IOS Safari 6.1.3
Safari 7.0

Summary:

IE series (only IE6 and 10 are listed in the table, in fact ie6-ie10 have been measured) does not support hostonly cookies. The cookie,www.qgy18.com set in the qgy18.com can be obtained directly.

Other browsers support hostonly cookies. In this test, for non-ie: Get cookie page domain is www.qgy18.com, because the cookie is not specified domain, according to the previous rule, Host-only-flag is true, The domain property of the cookie is qgy18.com, which does not exactly match, so the cookie is not available.

For non-hostonly cookies, such as specifying domain as qgy18.com when setting a cookie in qgy18.com, the cookie can be obtained at www.qgy18.com, when Host-only-flag is false.

Cookie Overlay Test

In www.qgy18.com, set the following 3 cookies:

-Shrinkage HTMLCode Run code[If the run is ineffective, save the source code as an HTML file], NAME=QUQU1; Expires=tue, 10-jul-2013 08:30:18 GMT; path=/
, NAME=QUQU2; Expires=tue, 10-jul-2013 08:30:18 GMT; path=/; Domain=.www.qgy18.com
, NAME=QUQU3; Expires=tue, 10-jul-2013 08:30:18 GMT; path=/; Domain=www.qgy18.com

Visit www.qgy18.comto obtain a cookie with the following results:

Browser	cookies acquired in www.qgy18.com
Chrome 29.0.1547.3 Dev	NAME=QUQU1; Name=ququ3
Firefox 22.0	NAME=QUQU1; Name=ququ3
Chrome 27.0.1453.116 m	NAME=QUQU1; Name=ququ3
IE 6.0.2900.5512	Name=ququ3
IE 10.0.9200.16438	Name=ququ3
Opera 12.15 (Presto core, non-webkit)	Name=ququ3
IOS Safari 6.1.3	NAME=QUQU3; Name=ququ1
Safari 7.0	NAME=QUQU3; Name=ququ1

There are two points in the specification that need to be stated first:

1. When setting a cookie, the domain property value if it is. a.com, the preceding. will be removed and become a.com (rfc6265 5th. 2.3);
2. For the same cookie as name, path, and domain, the following covers the preceding (rfc6265 section 5.3, 10th);

Summary:

Since the IE series does not support hostonly cookies, three statements are exactly the same for IE (1 does not specify domain, automatically uses the host in the request header or the domain portion of the page URL as the domain property of the Cookie. are www.qgy18.com), the back covers the front, leaving only name=ququ3;

Differences between opera in the Presto kernel and chrome, Safari, and Firefox: Opera believes that the three statements have the same name, path, and domain, resulting in the same results as IE. Other browsers think that Host-only-flag is true for domain and the other two different, so only statement 3 can overwrite 2, leaving 1 and 3;

The cookie information displayed from the respective consoles confirms this:

Chrome, Safari, and Firefox all display the hostonly cookie domain as a real domain, with a full stop in front of the domain for non-hostonly cookies. In this way, the previous results seem to explain the past: for Chrome, Safari and Firefox, because of the existence of. The 1th statement's domain and the other two are really different and will not be overwritten.

(Chrome 29.0.1547.3 Dev)

(Firefox 22.0)

(Safari 7.0)

(Opera 12.15)

(IE 10.0.9200.16438)

You should be aware of this: in this section of the test, Safari gets a different order of cookies than other browsers. This is a big risk, whether it is to use JS or HTTP to get this demo cookie, will be under Safari to get different results. Priority of cookies I'm going to take the time to do a detailed test, and then discuss it separately.

Conclusion

In the browser I have tested:

• Except Ie,chrome/firefox/safari/opera supports hostonly cookies, you can restrict cookies to be available only when domain is fully matched;
• Opera's hostonly cookie is overwritten by the same non-hostonly cookie as domain, path, and name;
• Chrome/firefox/safari, the domain property of a non-hostonly cookie is preceded by one more., with No. The hostonly cookie does not exist to cover the possibility;
• The cookie priority of the same name exists browser differences, the actual project should avoid the same name cookie;

Previous classmates asked the chrome developer to see why some of the cookies were earlier. After the previous analysis, we should all know why.

In addition, can not think of why Host-only-flag, not like Http-only-flag or Secure-only-flag, have the corresponding attributes directly set it?

Source: http://ju.outofmemory.cn/entry/36099

Hostonly Cookies and HttpOnly cookies