Cookie/Session mechanism and security, cookiesession Mechanism

Cookie/Session mechanism and security, cookiesession Mechanism

Cookie and Session are used to maintain the Session status on the stateless HTTP protocol, so that the server can know which client is currently dealing. This article discusses in detail the implementation mechanism of cookies and sessions, as well as the security issues involved.

Because the HTTP protocol is stateless, that is, when a user request arrives at the server, the HTTP server does not know who the user is or whether the user has logged on to the server. The reason why the current server knows whether we have logged on is that the server has set the browser Cookie when logging on! Session is a Session between a higher-level server and a browser through cookies.

Cookie was invented by Lou Montulli, a former employee of Netscape in 1993. Today, cookies are widely used.

Cookie Implementation Mechanism

A Cookie is a small text file stored by a client. Its content is a series of key-value pairs. The Cookie is set by the HTTP server and saved in the browser. When a user accesses other pages, the Cookie set before the server is attached to the HTTP request. Cookie implementation standards are defined in RFC2109: HTTP State Management Mechanism. How does Cookie work? The following describes the entire Cookie Transfer Process:

1. The browser initiates an HTTP request to a URL (for example, GET a page or POST a logon form)

2. The corresponding server receives the HTTP request and calculates the HTTP response that should be returned to the browser.

   The HTTP response consists of the request header and request body. For more information, see read HTTP.

3. Add in Response HeaderSet-CookieField. Its value is the Cookie to be set.

   As mentioned in RFC2109 6.3 Implementation Limits, UserAgent (a browser is a user agent) should support at least 300 cookies, and each item should support at least 4096 bytes, each domain name supports at least 20 cookies.

4. The browser receives an HTTP response from the server.

5. The browser found in the Response HeaderSet-CookieThe value of this field is stored in the memory or hard disk.

   Set-CookieThe field value can be multiple Cookie items, and each item can specify the expiration time.Expires. The default expiration time is when the user closes the browser.

6. When the browser sends an HTTP request to the server, the Cookie set by the server is appended to the header field of the HTTP request.Cookie.

   The browser can store cookies under multiple domain names, but only send the Cookie that has been specified for the domain name of the current request. This domain name can also be stored inSet-CookieField ).

7. The server received the HTTP request and found that the request header containsCookieField.

8. Expired cookies will be deleted by the browser.

In short, the server passesSet-CookieThe response header field indicates that the browser saves the Cookie.CookieThe request header field to tell the server the previous status. A Cookie contains several key-value pairs. You can set the expiration time for each key-value pair.

Cookie Security Risks

Cookie provides a means for an HTTP request to append the current status. Today's websites also rely on cookies to identify the user's logon status:

1. A user submits a user name and password form, which is usually a post http request.
2. The server verifies the user name and password. If the password is valid, the system returns 200 (OK) and setsSet-CookieIsauthed=true.
3. The browser stores the Cookie.
4. When the browser sends a request, SetCookieThe field isauthed=true.
5. The server receives the second request fromCookieThe field indicates that the user has logged on. Process the request according to the permissions of the logged-on user.

Where is the problem?

We know that not only browsers can send HTTP requests, but many HTTP client software (including curl and Node. js) can send arbitrary HTTP requests and set any header fields. If we directly setCookieThe field isauthed=trueAnd send the HTTP request. Isn't the server cheated? This attack is very easy. Cookies can be tampered!

Cookie tamper-Proofing Mechanism

The server can generate a signature for each Cookie. Because the user cannot generate a signature after the Cookie is tampered with, the server can know that the user has tampered with the Cookie. A simple verification process may be as follows:

1. Configure an unknown string (we call it Secret) in the server, for example:x$sfz32.
2. When the server needs to set cookies (for exampleauthed=false), Not only setauthedIsfalse, Set a signature after the value, and the final Cookie isauthed=false|6hTiBl7lVpd1P.
3. Signature6hTiBl7lVpd1PIs generated as follows:Hash('x$sfz32'+'true'). The value to be set is added to the Secret and then hashed.
4. The user receives the HTTP Response and finds the header fieldSet-Cookie: authed=false|6hTiBl7lVpd1P.
5. The user tampered with the HTTP requestauthedValue, set the header fieldCookie: authed=true|???. Because you do not know the Secret, you cannot generate a signature. You can only enter one.
6. The server received an HTTP request and foundCookie: authed=true|???. The server starts Verification:Hash('true'+'x$sfz32')The signature provided by the user is incorrect.

By adding a signature to the Cookie, the server can know that the Cookie has been tampered. However, the story is not over.

Because cookies are transmitted in plain text, once the server is setauthed=true|xxxxI don't knowtrueThe signature isxxxxThen, you can use this signature to cheat the server. Therefore, it is best not to include sensitive data in cookies. Generally, only one Session Id is put in the Cookie, and the Session is stored on the server.

Session Implementation Mechanism

Session is stored on the server side, avoiding storing sensitive data in client cookies. Sessions can be stored in the memory of the HTTP server or in a memory database (such as redis). heavyweight applications can even be stored in the database.

The Session stored in redis is used as an example to test how to verify the user logon status.

1. The user submits a form containing the user name and password and sends an HTTP request.
2. The server verifies the username and password sent by the user.

3. If correct, store the current user name (usually a user object) in redis and generate its ID in redis.

   This ID is called the Session ID. Through the Session ID, you can retrieve the corresponding user object from Redis, sensitive data (suchauthed=true) Are stored in this user object.

4. Set CookiesessionId=xxxxxx|checksumAnd send an HTTP response. The signature is still set for each Cookie.

5. After receiving the HTTP response, the user cannot see any sensitive data. This Cookie is sent to the server in the subsequent request.

6. After the server receives the subsequent HTTP request, it finds that the Cookie contains the SessionID for verification.

7. If the verification is passed, the corresponding user object is retrieved from Redis Based on the ID, the status of the object is viewed, and the business logic is continued.

The Web application framework implements the above process and can directly obtain the current user in the Web application. It is equivalent to implementing persistent sessions through cookies over HTTP. This Session is called a Session.

Unless indicated, this blog post is original, reprinted please in the form of a link to indicate the address: http://harttle.com/2015/08/10/cookie-session.html

Copyright Disclaimer: This article is the original article of the blogger. For more information, see the original article link.