Cookie Security (1)

2.5.4 Cookie Security (1)

Cookies are a magical mechanism in which any request from a browser in the same domain takes a cookie, no matter what resource is requested, and the cookie appears in the cookie field of the request header. The Set-cookie field of the server-side response header can add, modify, and delete cookies, and in most cases the client can add, modify, and delete cookies through JavaScript.

Because of such a mechanism, cookies are often used to store user's session information, for example, after the user login authenticated session, after the same domain request will be issued after the authentication of the conversation information, very convenient. So attackers are particularly fond of stealing cookies, which is tantamount to stealing user rights on the target site.

The important fields for cookies are as follows:

[Name] [Value] [Domain] [Path] [Expires] [HttpOnly] [Secure]

The meaning is: name, value, domain name, relative root path, expiration time, whether there is a httponly flag, whether there is a secure flag. These fields are good, cookies are safe, and the key fields are described below.

1. Subdomain cookie mechanism

This is the mechanism of the domain field, which is the default if you do not specify a value in domain if you set cookies. For example, the a.foo.com domain uses JavaScript to set up a cookie with the following statement:

Document.cookie= "Test=1";

The domain value defaults to a.foo.com. Interestingly, when the a.foo.com domain sets cookies, you can specify domain as the parent field, such as:

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

At this point, domain becomes foo.com, and the benefit is that cookies can be shared in different subdomains, and it is also obvious that other subdomains controlled by the attacker can read the cookie. In addition, this mechanism does not allow the setting of the cookie domain as the next subdomain or other Outland.

2. Path cookie mechanism

This is the mechanism of the path field, where the default is the path of the destination page if you do not specify a value for path when setting cookies. For example, the a.foo.com/admin/index.php page uses JavaScript to set up a cookie with the following statement:

Document.cookie= "Test=1";

The path value is/admin/. By specifying the Path field, JavaScript has permission to set any cookie to any path, but only page JavaScript under the target path can read the cookie. So what's the way to read cookies across paths? For example, the/evil/path wants to read a cookie for the/admin/path. Quite simply, the code for the page under the/evil/path is as follows: The DOM is manipulated across the IFRAME.

XC = function (src) {

var o = document.createelement ("iframe"); IFrame enters the target page of the same domain

O.SRC = src;

document.getElementsByTagName ("Body") [0].appendchild (O);

O.onload = function () {//After the IFRAME has finished loading

d = O.contentdocument | | O.contentwindow.document;

Get Document Object

alert (D.cookie); Get cookies

};

} (' http://a.foo.com/admin/index.php ');

Therefore, setting path does not prevent important cookies from being stolen.

3. HttpOnly cookie Mechanism

As the name suggests, HttpOnly refers to 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, which effectively defenses against XSS attacks to get cookies. For example, in PHP Setcookie, the httponly.php file code is as follows:

<?php

Setcookie ("Test", 1, Time () +3600, "", "", 0); Set Common cookies

Setcookie ("Test_http", 1, Time () +3600, "", "", 0, 1);

The 7th parameter (the last one here) is the HTTPONLY flag, 0 is off, 1 is open, and the default is 0.

?>

When this file is requested, two cookies are set, as shown in Figure 2-2.

Where Test_http is a httponly Cookie. Is there any way to get a httponly Cookie? If the server-side response page has cookie debugging information, it is likely to cause a httponly cookie to leak. For example, the following information