HTTP Cookie Learning

Cookie Introduction:

Cookies (plural form cookies), Chinese names are small text files or cookies, which are data (usually encrypted) stored on the user's local terminal (client Side) by certain websites in order to identify user identities. Defined in RFC2109. Was the invention of Netscape's former employee Lou Montulli in March 1993.

Concept: A cookie is any piece of text that is sent to a browser under Web server. In subsequent HTTP requests, the browser brings the cookie back to the Web Server.

Cookie effect:

Because the HTTP protocol is stateless , that is, the server does not know what the user did last time, which seriously hinders the implementation of the interactive Web application .

In a typical online shopping scene, users browsed through several pages, bought a box of biscuits and two bottles of drinks. At the end of checkout, due to the stateless nature of HTTP, the server does not know what the user is buying without additional means. So a cookie is one of the stateless "extras" that can be used to bypass HTTP. The server can set or read the information contained in the cookie to maintain the status of the user and the server session .

In the shopping scene just now, when the user buys the first item, the server sends a cookie to the user while sending the webpage, which records the information of the product. When a user accesses another page, the browser sends the cookie to the server, and the server knows what he has previously purchased. The user continues to buy drinks, and the server adds new product information to the original cookie. At checkout, the server reads the cookie that is sent.

If there is no cookie:

1. Each visit is like a first visit, and it is not possible to tell if a user has accessed

2. Any purchase, such as interaction, verification behavior must be completed in one visit

3. Without any memory, users need to re-click or fill in

Memory cookies and hard disk cookies

This should be well understood, one is the existence of memory, the existence of a hard disk. The difference is in the effective time of the cookie.

Memory Cookie: maintained by the browser, stored in memory, the browser is closed and disappears, its existence time is short.

hard disk Cookie: saved in the hard disk, there is an expiration time, unless the user manually clean up or to expire time , the hard disk cookie will not be deleted, its existence time is long-term.

The use of hard disk cookies:

When you log in to a website, the site often asks the user for a user name and password, and the user can tick "next automatic login". If checked, the next time you visit the same website, users will find that they have logged in without entering their username and password. This is precisely because the server sent a cookie containing the login credentials (an encrypted form of the user name plus a password) to the user's hard disk the previous time you logged on. On the second login, (if the cookie is not yet expired) The browser sends the cookie, the server verifies the credentials, and the user does not have to enter a user name and password to log in.

Cookie classification:1. Session Cooiek

This type of cookie is only valid for the duration of the session, that is, when the browser is closed, it will be deleted by the browser. The session cookie is set by creating a cookie without setting the expires.

2. Persistent cookies

Persistent cookies, as the name implies, will take effect for a long time in a user session. When you set the property of the cookie to max-age for 1 months, the cookie will be in the HTTP request for each relevant URL in this month. So it can record a lot of user initialization or custom information, such as when the first login and weak login state and so on.

3. Secure Cookie

A security cookie is a cookie pattern under HTTPS access to ensure that cookies are always encrypted as they are passed from the client to the server. Doing so greatly reduces the probability that the cookie content is directly exposed to the hacker and stolen.

4. HttpOnly Cookies

HttpOnly cookies are now supported by mainstream browsers. 1.ie5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.safari/chrome. cookies set to HttpOnly can only be passed on HTTP (HTTPS) requests on browsers that support HttpOnly. This means that the HttpOnly cookie is not valid for client-side scripting language (JavaScript), thus avoiding the case of JS stealing cookies when cross-site attacks. When you use JavaScript to set a cookie of the same name, only the original HttpOnly value is transferred to the server.

5.3rd-party Cookies

A first-party cookie is a cookie planted under the domain name or subdomain of the browser's address bar. Third-party cookies are planted under a domain name that differs from the browser's address bar. For example, when a user accesses a.com, a cookie is set in ad.google.com and a cookie is set in ad.google.com when accessing B.Com. This scene often appears in Google AdSense, Ali mom and other advertising services. Advertisers can collect some of the user's habits and access history.

6. Super Cookie

A super cookie is a cookie that is set on a public domain name prefix. Normally a.b.com cookies can be set on a.b.com and B.Com, but not on. com, but unfortunately some older browsers in history have caused super-cookies because of insufficient filtering of new suffixes.

Implementation of cookiesDelivery process:

Take a visit to this site (www.kryptosx.info) for example.

Here, fiddler is used to make HTTP packets, which are used to analyze how the cookie is passed during the interaction.

The first step:

Use the browser to open Www.kryptosx.info, which is a GET request.

As can be seen, the first request, there is no information on cookies, but the return packet, there is Set-code head, followed by the cookie information.

As you can see, all three of them are delete cookies-"=deleted". Cookies are httponly. In addition, expires is set to 1970, this cookie becomes the so-called Session-cookie. Because the browser automatically cleans out expired cookies.

The second step is to refresh this page:

This is still a GET request, but with a cookie.

Get/http/1.1accept:text/html, Application/xhtml+xml, */*accept-language:zh-hans-cn,zh-hans;q=0.8,en-us;q=0.5,en; q=0.3user-agent:mozilla/5.0 (Windows NT 6.3; WOW64; trident/7.0; rv:11.0) Like Geckoaccept-encoding:gzip, Deflatehost:www.kryptosx.infodnt:1connection:keep-alivecookie: cnzzdata1254085044=1980544601-1431063029-%7c1431063029

Of course, the return package also has a cookie.

Summarize:

From the capture package, you can see how the cookies are passed when HTTP interacts. Of course, my cookie here is estimated to be access statistics.

Cookies are interactive between a browser and a server and are not dependent on a single Web page. Browsers are distinguished by domain. We can also see from the accompanying information that it has nothing to do with post or get.

Cookie and cross-site request forgery (CSRF):

Cookies can be viewed as a credential and will naturally be hacked by hackers. As long as you steal it, the attacker can impersonate your identity.

Perhaps one day, you receive an e-mail, it tells you that your XXX network account is risky, please modify immediately. There is also a link, you find that the link is true, is the XXX network domain name . You may not have noticed, just open it. After that, you will find that the password in your XXX system has been changed.

This is a csrf attack, and the attacker has crafted a URL. This URL comes with a GET request to change the password. In addition, your browser keeps the cookies on the XXX web locally, so the operation is legal.

CSRF has other tools, such as embedding images in a Web page, which are more subtle.

Solution:

CSRF looks terrible, but it can be solved. Of course this kind of thing can not rely on the user, or the website developer to take care of.

CSRF uses cookies because cookies are a browser-level message, and the same cookies can be accessed on different pages of the same Web site with a single browser. The attacker's request is therefore legitimate for the browser, the server does not do CSRF protection, and the request is considered legitimate, so it is attacked.

As I said before,cookies are a voucher, but cookies are browser-level and can be used by the same browser, so hackers can use them as well. Then we can get a voucher, so that the hacker could not use, do not solve, and then this example, the legal change password operation is to open the Change Password page first, the password to change, and then click Submit. And the hacker is directly submit the request, and did not open the Change Password page this step.

Therefore, the current anti-CSRF attack methods, mostly in the Web page to add a token, that is, put a voucher on the page , which is the page level, hackers can not use this credential, CSRF attack is difficult to carry out.

There is also the use of verification code, this is certainly more secure, in addition, there is the ability to prevent brute force, but the user experience is not very good. So generally put in important operations, such as changing the password this type: P.

In addition, some people say that using the post is safe, post relative to get is really better, after all, forged post difficult point. But don't think you can dodge the CSRF. The JS script is capable of simulating a POST request. So add token or token.

Reference: http://www.webryan.net/2011/08/wiki-of-http-cookie/

HTTP Cookie Learning