HTTP Cookie and Session

1. Cookies

The HTTP protocol is stateless , mainly to make the HTTP protocol as simple as possible so that it can handle a large number of transactions. HTTP/1.1 introduces cookies to save state information .

A cookie is a small piece of data sent by the server to the user's browser and stored locally . It will be carried when the browser initiates a request to the same server again , and is used to tell the server whether the two requests come from the same browser. Since each subsequent request will need to carry Cookie data, it will bring additional performance overhead (especially in a mobile environment).

Cookies were once used to store client-side data, because there were no other suitable storage methods at that time, and they were used as the only storage method, but now as modern browsers begin to support various storage methods, cookies are gradually eliminated. New browser APIs already allow developers to store data directly locally, such as using the Web storage API (local storage and session storage) or IndexedDB.

1.1 Purpose of Cookies

Session state management (such as user login status, shopping cart, game score or other information that needs to be recorded)
Personalization settings (such as user-defined settings, themes, etc.)
Browser behavior tracking (such as tracking and analyzing user behavior, etc.)

1.2 Cookies creation process

The response message sent by the server contains the Set-Cookie header field, and the client saves the Cookie content in the browser after receiving the response message.

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

When the client sends a request to the same server later, it will fetch the Cookie information from the browser and send it to the server through the Cookie request header field.

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

1.3 Cookie classification

Session Cookie: It is automatically deleted after the browser is closed , which means it is only valid for the session period.
Persistent Cookie: After the specified expiration time (Expires) or validity period (max-age), it becomes a persistent cookie.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

1.4 Cookies scope

Domain identifies which hosts can accept cookies. If not specified, defaults to the host of the current document (excluding subdomains). If Domain is specified, subdomain names are generally included. For example, if Domain=mozilla.org is set, cookies are also included in subdomains (such as developer.mozilla.org).

The Path identifier specifies which paths under the host can accept cookies (the URL path must exist in the request URL). With the character %x2F ("/") as a path separator, subpaths are also matched. For example, if Path=/docs is set, the following addresses will match:

/docs
/docs/Web/
/docs/Web/HTTP

1.5 HttpOnly and Secure flags

The browser can create a new cookie through document.cookie the attribute , and can also access the non-HttpOnly marked cookie through this attribute.

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);

Cookies marked as HttpOnly cannot be called by JavaScript scripts . Cross-site scripting attacks (XSS) often use JavaScript's document.cookie API to steal user cookie information, so using the HttpOnly tag can avoid XSS attacks to a certain extent.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Cookies marked as Secure can only be sent to the server through requests encrypted by the HTTPS protocol . But even if the Secure flag is set, sensitive information should not be transmitted through Cookies, because Cookies are inherently insecure , and Secure flags cannot provide real security.

2. Session

In addition to storing user information in the user's browser through Cookie , it can also use Session to store on the server side , and the information stored on the server side is more secure .

Sessions can be stored in files, databases, or memory on the server . It is also possible to store the Session in an in-memory database such as Redis , which will be more efficient.

The process of using Session to maintain user login status is as follows:

When the user logs in, the user submits a form containing the user name and password, and puts it into the HTTP request message;
The server verifies the user name and password, and if it is correct, it stores the user information in Redis, and its Key in Redis is called Session ID;
The Set-Cookie header field of the response message returned by the server contains the Session ID, and the client stores the Cookie value in the browser after receiving the response message;
The cookie value will be included when the client makes a request to the same server later, and the server extracts the Session ID after receiving it, extracts the user information from Redis, and continues the previous business operation.

Attention should be paid to the security of the Session ID , and it cannot be easily obtained by malicious attackers, so an easily guessed Session ID value cannot be generated. In addition, the Session ID needs to be regenerated frequently. In scenarios with high security requirements, such as transfers and other operations, in addition to using Session to manage user status, users also need to re-authenticate, such as re-entering passwords or using SMS verification codes.

When the browser disables cookies, cookies cannot be used to save user information, only Session can be used . In addition, the Session ID can no longer be stored in the cookie, but the URL rewriting technology is used to pass the Session ID as a parameter of the URL.

3. Cookie and Session selection

Cookie can only store ASCII code strings , while Session can store any type of data , so Session is preferred when considering data complexity;
Cookies are stored in the browser and are vulnerable to malicious viewing. If you have to store some private data in a cookie, you can encrypt the cookie value and then decrypt it on the server;
For large websites, if all user information is stored in Session, the overhead is very high, so it is not recommended to store all user information in Session.

References: