Cookie Security Summary

Cookie mechanism: In general, any request made by a browser within the same domain will be brought with a cookie, regardless of the resource requested, and the cookie appears in the cookie field of the request header, if requested. The Set-cookie field of the service-side response header can add, modify, and delete cookies, and clients can add, modify, and delete cookies through JavaScript as well. In addition, cookies cannot exist across browsers.

Using the cookie mechanism, we can store the user's session information, for example, the user after the authentication of the session, and then the same domain in the request will be issued after the authentication session information, very convenient. As a result, attackers are particularly fond of stealing cookies, which is tantamount to stealing user rights on the target site.

Of course, sometimes cookie reading of static components is a waste, and we can use another cookie-free domain to hold these static components.

The important fields for cookies are as follows:

[Name] [Value] [Domain] [Path] [Expries] [Max-age] [HttpOnly] [Secure]

The meanings are: name, value, owning domain name, relative root path, expiration time, whether there is a httponly flag, whether there is a secure flag.

The domain, path, httponly, and secure fields are described separately below:

1. Subdomain cookie mechanism

When setting a cookie, if you do not specify a value for domain, the default is the domain.

For example: The a.foo.com domain uses JavaScript to set a cookie with the following statement:

Document.cookie= "Test=1";

Then, the domain value defaults to a.foo.com. If you specify domain as the parent field, such as:

Document.cookie= "test=1;domain=foo.com";

At this point, domain becomes foo.com, which has the advantage of being able to share cookies in different sub-domains, as well as the disadvantage of being able to read this cookie on other subdomains controlled by the attacker. Note: This mechanism does not allow domain settings for cookies to be the next level subdomain or other domain.

2. Path cookie mechanism

When setting a cookie, if you do not specify a value for path, the default is the path to the destination page.

For example: The a.foo.com/admin/index.php page uses JavaScript to set a cookie with the following statement:

Document.cookie= "Test=1";

Then, the path value defaults to/admin/. By specifying the path field, JavaScript can set any cookie to any path, but only page JavaScript under the target path will be able to read the cookie.

However, setting path does not prevent important cookies from being stolen. For example, the/evil/path wants to read the cookie of the/admin/path. By DOM manipulation across the IFRAME, the code for the page under the/evil/path is as follows:

xc=function(src) {    var o=document.createelement (' iframe ');   The IFRAME enters the target page of the same domain    o.src=src;    document.getElementsByTagName (' body ') [0].appendchild (o);    O.onload=function() {//d=o.contentdocument|after the iframe loading is complete        | O.contentwindow.document; // Get Document Object        alert (D.cookie); // Get Cookies     };} (' http://a.foo.com/admin/index.php ');

3. HttpOnly cookie Mechanism

HttpOnly is a cookie that is transmitted only at the HTTP level, and when the HTTPONLY flag is set, client script cannot read and write the cookie and can effectively defend against XSS attacks to obtain cookies. Take PHP Setcookie as an example, the httponly.php file code is as follows:

<? PHP Setcookie ("Test", 1,time () +3600, "", "", 0,0);    // set up a normal cookie Setcookie ("Test_http", 1,time () +3600, "", "", 0, 1); // The 7th parameter (the last one here) is the HTTPONLY flag, 0 is off, 1 is on, and the default is 0?>

After requesting this file, a two cookie is set, as shown in:

Of these, Test_http is a httponly Cookie. If the server responds to a page that has cookie debugging information, it is likely to cause a leak of the HttpOnly cookie. such as the following information.

Apache http server2.2.x Multiple versions do not strictly restrict the HTTP request header information, the HTTP request header exceeds the limitrequestfieldsize length, the server returns the (Bad Request) Error and the output of the requested header content (which contains the HttpOnly cookie in the request head) in the return message, an attacker could exploit the flaw to obtain the HttpOnly cookie.

Most browsers restrict cookies (50 cookies per domain) to a maximum of approximately 4kB, and we set it to a larger and local cookie, which causes the request header length to exceed Apache's limitrequestfieldsize, resulting in a 400 error. Such an attacker would only be able to access the target Web site properly by clearing the cookie.

4. Secure cookie Mechanism

The secure cookie mechanism means that a cookie with the secure flag is transmitted securely at the HTTPS level only and will not be brought with this cookie if the request is HTTP, thus reducing the risk of an important cookie being intercepted by a middleman.

However, Secure cookies are read-write to client-side scripting, which means that they can be stolen and tampered with. The following JavaScript scripting code can tamper with a known secure cookie:

// path must be consistent with domain, otherwise it will be considered a different cookiedocument.cookie= "test_secure=1;path=/;secure;"

Local Cookies and memory cookies

If the expiration time is not set, it is a memory cookie, which disappears from memory as the browser shuts down, and if the expiration is set to a future point in time, then it is a local cookie, which is stored as text in the operating system locally. It will not disappear until the expiration time is up. Such as:

Document.cookie= "test_expires=1;expires=mon,01 Jan 2112 00:00:00 GMT"; // GMT Time, January 1, 2112 only expires

The use of local cookies allows users to not need to log in for a certain period of time in the future to improve the user experience, but if the attacker obtains such a local cookie through XSS, it will be possible for a long time in the future, or even permanently control the target user's account permissions. This does not mean that memory cookies are more secure, because an attacker could add an expiration time to a memory cookie to make it a local cookie.

P3P Nature of Cookies

The P3P (Platform for Privacy Preferences Project) field of the HTTP response header is a recommended standard for privacy protection published by the public. This field is used to identify whether the cookie for the target site is allowed to be set up or sent by another domain by loading the destination Web site, but IE only executes the policy.

For example, the evil domain loads the Foo domain through script or IFRAME. When loading, whether the browser will allow the Foo domain to set its own cookie, or whether to allow sending requests to the Foo domain, bring the existing cookie in the Foo domain.

Here are the two scenarios where the P3P strategy is set up and sent, and the P3P strategy is different in these two scenarios:

1. Set Cookies

Under IE, the default is not to allow third-party domains to set cookies (local and memory) unless the Foo domain takes the P3P field in response, such as:

p3p:cp= "CURa ADMa DEVa Psao psdo our BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"

The content of the field itself is not very meaningful, do not need to remember (of course, we do not have time to remember the things that have no special meaning), as long as the knowledge of this setting, the loaded target domain cookie can be set to normal, After setting the cookie, the P3P attribute (which is not visible in the cookie) is automatically taken under IE, and is effective once, even if there is no P3P header.

2. Sending cookies

If the cookie is a memory cookie, it just doesn't matter if there is a P3P attribute, it can be sent normally, if it is a local cookie, the local cookie must have the P3P attribute, otherwise, even if the target domain responds to the P3P header.

We can test it in the following ways:

1) Add www.foo.com and www.evil.com domains to the host file.

2) Save the following code as foo.php and guarantee access through www.foo.com/cookie/foo.php.

<? PHP // header (' p3p:cp= ' CURa ADMa DEVa Psao psdo our BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR "'); Setcookie ("Test0", ' local ',time () +3600*3650); Setcookie ("Test_mem0", ' Memory '); Var_dump ($_cookie);? >

3) Save the following code as evil.php and guarantee access through www.evil.com/cookie/evil.php.

<iframe src= "http://www.foo.com/cookie/foo.php" ></iframe>

4) IE browser access www.evil.com/cookie/evil.php, because there is no response to P3P header, foo.php settings did not succeed.

5) Remove the comments from the foo.php P3P response function, and then visit www.evil.com/cookie/evil.php to discover that both the local cookie (TEST0) and the Memory cookie (TEST_MEM0) have been set successfully.

6) Modify the cookie name in the foo.php, for example, test0 change to Test1,test_mem0 to Test_mem1, comment p3p response function, and then directly access www.foo.com/cookie/ foo.php, the local cookie (test1) and the Memory cookie (TEST_MEM1) are set, and none of the two cookies have the P3P attribute at this time.

7) by accessing www.evil.com/cookie/evil.php, the memory cookie (TEST_MEM1) can be found to be sent normally, while the local cookie (test1) is not sent.

8) Continue to modify the foo.php in the cookie name, test1 instead of test2,test_mem1 to test_mem2, remove the P3P response function comments, and then directly access www.foo.com/cookie/ Foo.php, both the local cookie (TEST2) and the Memory cookie (TEST_MEM2) have P3P properties.

9) Visit www.evil.com/cookie/evil.php at this time, you can find Test2 and test_mem2 are sent out.

Cookie Security Summary