About the cookie and session mechanism in HTTP

Objective

The cookie was invented by Netscape's former employee Lou Montulli in 1993. Pay tribute to the seniors.

1. Cookie and Session Introduction

Cookies and sessions are designed to maintain session state on top of the stateless HTTP protocol, allowing the server to know which customer is currently working. Because the HTTP protocol is stateless, that is, each time a user requests to the server, the HTTP server does not know who the user is, whether they have logged in, and so on. The server now knows if we are logged in because the server set the browser's cookie! at login A session is a higher-level server-to-browser conversation that is implemented by a cookie.

2. Cookie Implementation Mechanism

A cookie is a small text file that is saved by a client and whose contents are a series of key-value pairs. Cookies are set by the HTTP server and are saved in the browser, and when the user accesses another page, the cookie that was set before the server is appended to the HTTP request. The implementation criteria for cookies are defined in Rfc2109:http State Management mechanism, so how does a cookie work? The following gives the entire cookie delivery process:

1. The browser (or client) initiates an HTTP request to a URL (can be any request, such as get a page, post a login form, etc.)

2. The corresponding HTTP server receives the HTTP request and calculates the HTTP response that should be returned to the browser. The _ps_http response includes both the request header and the request body.

3. In the response header, add the Set-cookie field, and its value is the cookie to be set.

4. The browser (or client) receives an HTTP response from the server.

5. When the browser finds the Set-cookie field in the response header, the value of the field is saved in memory or on the hard disk. The value of the Set-cookie field can be many items of cookies, each of which can specify an expired

Time expires. The default expiration time is when the user closes the browser.

6. The next time the browser sends an HTTP request to the server, the server-set cookie is appended to the HTTP request's header field cookie. Browsers can store cookies under multiple domain names, but only send the current

The requested domain name has been specified by the cookie, and this domain name can also be specified in the Set-cookie field.

7. The server receives this HTTP request and discovers that there is a cookie field in the request header and knows that it has dealt with the user before. This distinguishes the browser (or client).

8. Expired cookies are deleted by the browser (or client).

In summary, the server instructs the browser to save the cookie through the Set-cookie response header field, which the browser uses to tell the server the status before the cookie. A cookie contains several key-value pairs, each of which can set an expiration time. 3. Security implications of cookies

Cookies provide a means by which HTTP requests can be appended to the current state, and now Web sites rely on cookies to identify the user's login status:

1. The user submits a form for the user name and password, which is usually a post HTTP request.

2. The server verifies the user name and password, and if it is legal, returns a number of (OK) and sets Set-cookie to authed = ture.

3. The browser stores the cookie.

4. When the browser sends the request, set the cookie field authed = ture.

5. The server receives a second request and learns from the cookie field that the user is logged in. Handle this request in accordance with the permissions of the logged-on user

What's the problem in this?

We know that it is not just the browser that can send HTTP requests, many HTTP client software can also send arbitrary HTTP requests and can set any header fields. If we set the cookie field directly authed = True

and send the HTTP request, the server is not deceived? This attack is very easy and cookies can be tampered with!

4. Cookie anti-tampering mechanism

The server can generate a signature for each cookie entry, and the server can be informed that the user has tampered with the cookie because the user cannot generate the corresponding signature after tampering with the cookie. A simple verification process might be this:

1. Configure a non-known string in the server (we call it secret), such as: X$sfz32.
2. When the server needs to set a cookie (such as Authed=false), not only set the value of authed to False, further set a signature after the value, the final set of the cookie is authed=false|6htibl7lvpd1p.
3. The signature 6htibl7lvpd1p is generated in this way: Hash (' x$sfz32 ' + ' true '). The value to be set is added to the secret and then hashed.
4. The user receives an HTTP response and discovers the header field set-cookie:authed=false|6htibl7lvpd1p.
5. The user tampered with the authed value when sending the HTTP request, set the header field cookie:authed=true|???。 Because the user does not know secret, cannot generate the signature, can only fill in one.
6. The server received an HTTP request and found cookie:authed=true|???。 The server begins the checksum: Hash (' true ' + ' x$sfz32 ') and will find that the user supplied the signature is incorrect.

By adding a signature to the cookie, the server is able to know that the cookie has been tampered with. But the story isn't over, and it's still unsafe. Because the cookie is transmitted in plaintext, as long as the server is set once authed=true|xxxx I do not know the true signature is XXXX, you can use this signature to deceive the server. Therefore, it is best not to put sensitive data in cookies. In general, only a session Id is placed in the cookie, and the session is stored on the server side

5. Session Implementation Mechanism

The session is stored on the server side, avoiding the storage of sensitive data in the client cookie. The session can be stored in the HTTP server's memory or in a database, and for heavyweight applications can even

stored in the database. We take the session stored in Redis as an example to examine how to verify the user's login status.

1. The user submits a form containing a user name and password and sends an HTTP request.

2. The server verifies the user name and password sent by the user

3. If correct, store the current user name (usually the user object) in Redis and generate its ID in Redis. This ID is called the session ID, and the session ID allows the corresponding user to be removed from the Redis.

objects, sensitive data (such as authed=true) is stored in this user object.

4. Set the cookie to sessionId=xxxxxx|checksum send the HTTP response, and still set the signature for each cookie.

5. Once the user receives the HTTP response, they will not see any sensitive data. The cookie is sent to the server after this request.

6. After the server receives the HTTP request, it discovers that there is sessionid in the cookie, which is verified by the release tamper.

7. If authentication is passed, the corresponding user object is removed from Redis based on that ID, the state of the object is viewed and the business logic continues to execute.

The Web application framework implements the above-mentioned process and can get the current user directly in a Web application. Equivalent to the HTTP protocol, a persistent session is implemented through a cookie. This conversation is called a session.

About the cookie and session mechanism in HTTP