Node learning talks about the working principle of Cookie-Session login verification

At present, most systems are indispensable for the Login verification function. This is mainly to save the user's status and limit the user's various behaviors. This makes it convenient and effective to control user permissions. For example, when a user logs in to Weibo, the operations of posting, following, and commenting should be performed under the user status after login.

There are two main ways to implement login verification: Cookie&Session and JWT. In this section we will first discuss the Cookie&Session The working principle will be introduced in detail. In subsequent articles, we will successively introduce JWT and how to use Cookie&Session and JWT to improve what we have learned in the previous sections. The simple user management system built is explained. [Related tutorial recommendations: nodejs video tutorial]

1️⃣ Cookie&Session

We know that HTTP is stateless. In other words, the HTTP requester and responder cannot maintain state, it is all one-time, and it does not know what happened in the previous and subsequent requests. But in some scenarios, we need to maintain state. Most typically, when a user logs in to Weibo, posts, follows, and comments should be under the user status after login.

At this time, Cookie and Session can be introduced to save the user's login status.

This article mainly introduces the working principle of using Cookie-Session for login verification, about Cookie and For a detailed introduction to Session, please refer to this guy’s article: Cookie and Session Detailed Explanation

Why not use Cookie alone?

Cookie is stored in the browser. You can open the Console in the browser, select Application, and find#Cookie in storage is viewed:

When the client sends a network request to the server, the browser will

automatically Add Cookie to the request header so that the server can obtain this Cookie, as follows:

After knowing this principle, we can think of, if when the user logs in to the system: the client uses part of the user's login information (such as

username, id, etc.) Generate a Cookie and store it in the browser, then every subsequent network request will automatically carry the Cookie.

Then let the server determine whether the request carries

Cookie and whether there are valid username and id# in the Cookie ##To determine whether the user has logged in, won't the user's login status be saved? Go back to the Weibo example we mentioned above. According to this process, when the user logs in,

Cookie

has been saved. At this time, when the user publishes, follows, and comments When we need to log in to use the operation, we can determine in advance whether Cookie exists. If it exists and Cookie contains the user's id, then we can Allow these operations for the user (these operations generally require the user's id, which can be obtained from Cookie). On the contrary, if Cookie does not exist or Cookie is invalid, then these operations of the user are prohibited. Speaking of this, you may ask:

Since a

Cookie can achieve the effect we want, why should we use Session? This is because

Cookie is easily forged! , if we know that the information stored in Cookie is username and id (even if we don’t know, we can also make a request to the network after logging in Cookie is found in the body), then we can manually store a fake Cookie in the browser without logging in:

Speaking of this, you should be able to understand why

Cookie

cannot be used alone.

#How is Session combined with Cookie?

Session

is actually implemented based on Cookie, and Session is stored in the memory or database of the server.

When the user logs in successfully, the login verification using Cookie&Session will perform the following operations:

• is generated by the server Session and SessionId;

  Session is generally generated based on the user’s login information, such as user name, id, etc.
  If Session is compared to a lock, then SessionId is equivalent to the key of the lock.

• The server will store Session in memory or database;

• The server will store SessionId is stored in the Set-Cookie field in the request's response header (response object) and sent to the client;

• After receiving Set-Cookie, the client will automatically store the value of Set-Cookie (that is, SessionId) into Cookie;

• Every subsequent network request will automatically bring Cookie, that is, bring this SessionId;

• When the server receives a subsequent request, it obtains the Cookie on the request, that is, it obtains the SessionId, and then passes the SessionId Query and verify the Session stored on the server. If the verification is successful, it means that the SessionId is valid and the request will be passed. Otherwise, the request will be blocked.

Illustration:

##2️⃣ Cookie&Session defects

Storage issues

In order to save the user's login status, we need to generate and store

Session for each logged in user, which will inevitably cause the following problems :

If
• Session is stored in memory, then when the server restarts, the Session in these memories will be cleared, then all users’ The login status will expire, and when the number of users is large, excessive memory usage will inevitably affect the performance of the server.
If
• Session is stored in the database, although it can solve the problem of user login status expiration due to server restart, when the number of users is large, the maintenance of this database will also change. relatively difficult.
If the interface called in the front-end page comes from two servers (that is, two sets of databases), in order to achieve
• Session sharing between the two servers, the Session is usually Stored in a separate database, this makes the entire project more complex and difficult to maintain.
  

CSRF problem

CSRF is called Cross-site request forgery. Cross-site request forgery, websites that use Cookie for verification will face large or small CSRF threats, we use an example of a bank website to introduce CSRF Attack principle:

If a bank's

website A's login authentication uses Cookie&Session, and the transfer operation is used to run the # on the website ##Api address is: http://www.grillbankapi.com/?account=AccoutName&amount=1000

##api

Parameters:

account represents the account name, amount represents the transfer amount. Then, a malicious attacker can place the following code on another

website B

:

<img  src="/static/imghw/default1.png" data-src="http://www.grillbankapi.com/?account=Ailjx&amount=1000" class="lazy" alt="Node learning talks about the working principle of Cookie-Session login verification" >

Note:

img

The

src of the tag is the api address of the transfer operation of website A, and the parameter account is Ailjx, and amount is 1000 , that is to say, this api address is equivalent to the api called when the account name is Ailjx and transfers 1000. If a user with the account name Ailjx has just visited

website A

not long ago, the login information has not expired (

Cookie of website A exists and valid). Then when Ailjx visits this malicious website B

, the above

img tag will be loaded, and the browser will automatically request the img tag The src route is the request http://www.grillbankapi.com/?account=Ailjx&amount=1000 (we record this request as requestQ ), and because Cookie is stored in the browser and the browser will automatically bring Cookie when sending a request, so request Q will automatically carry Ailjx in The Cookie certificate on website A, the result is that this request Q will be passed , then Ailjx will lose 1000 funds .

This kind of malicious URL can take many forms and be hidden in many places on the web page. Additionally, the attacker does not need to control the website where the malicious URL is placed. For example, he can hide this address in forums, blogs, or any other website with user-generated content. This means that if there are no appropriate defense measures on the server side, users are still at risk of being attacked even if they visit familiar and trusted websites.

As can be seen from the example, the attacker cannot directly obtain the user's account control through CSRF attacks, nor can he directly steal any user information. What they can do is trick the user's browser into running operations on the user's behalf.

These are the problems with using Cookie&Session for login verification, so how do we solve these problems? This requires introducing the concept of JWT and using token for login verification, which we will explain in subsequent articles.

For more node-related knowledge, please visit: nodejs tutorial!

The above is the detailed content of Node learning talks about the working principle of Cookie-Session login verification. For more information, please follow other related articles on the PHP Chinese website!