Http stateless

HTTP stateless protocol, which means that the protocol has no memory for interactive scenarios

Reference blog.csdn.net/u014044812/…

Cookie

The origin of the Cookie

Lou Montulli, a Netscape employee at the time, applied the concept of “cookies” to Internet communications in 1994 to solve the shopping cart history of a user’s online shopping, and the most powerful browser at the time was Netscape. With the support of Netscape, other browsers gradually began to support cookies, and now all browsers support cookies. Cookie, sometimes also used in the plural, Cookies. The type is small text file. It is the data (usually encrypted) stored on the user’s local terminal by some websites for identifying the user’s identity and Session tracking, and temporarily or permanently stored by the user’s client computer.

The creation of a Cookie

After the user enters the user name and password, the browser sends the user name and password to the server for authentication. After the authentication is successful, the server encrypts the user information, encapsulates it into a Cookie, and sends it back to the browser in the request header.

HTTP/1.1 200 OK Content-Type: text/ HTML set-cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg; HTTP/1.1 200 OK Content-Type: text/ HTML set-cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Aug 2019 21:47:38 GMT; Path=/; Domain=.169it.com; HttpOnly [response body]Copy the code

The browser receives data from the server and finds a “set-cookie” in the request header. It stores the Cookie and sends it to the server in the request header the next time the browser requests the Cookie:

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg
Copy the code

Pay attention to

Cookies, whether sent from the server to the browser or from the browser to the server, are placed in the request header! Cookies store data on the client. 1. Session hijacking and XSS 2. Cross-site request Forgery (CSRF)Copy the code

The attribute of the Cookie

1.Name&Value

Name indicates the Name of the Cookie, and the server obtains a Cookie value through the Name attribute. Value indicates the Cookie Value. In most cases, the server will use this Value as a key to query the saved data in the cache.

2.Domain&Path

Domain Indicates the Domain name that can access the cookie. Access rules: TOP-LEVEL domains can only set or access cookies of top-level domains. Domain names at level 2 and below can only set cookies of themselves or top-level domains. So if you want to share cookies among multiple secondary domains, you can only set the Domain property to the top-level Domain! Path indicates the page Path from which this cookie can be accessed.

3.Expires/Max-Age

Expires/ max-age Indicates the cookie timeout period. If the value is set to a time, the cookie becomes invalid when the time is reached. If this parameter is not set, the default value is Session, which means that the cookie will expire with the Session. This cookie expires when the browser closes (not the browser TAB, but the entire browser). Tip: When Cookie expiration is set, the date and time are only relevant to the client, not the server.

4.Size

Size indicates the number of characters in the Cookie name+value. For example, if id=666, then Size=2+3=5. Also, every browser supports cookies differently

5.HTTP

HTTP represents the Httponly property of the cookie. If this property is true, the cookie is only contained in the HTTP request header and cannot be accessed through document.cookie. This feature is designed to provide a security measure to help prevent cookie theft through javascript-initiated cross-site scripting attacks (XSS)

6.Secure

Secure indicates whether this cookie can only be passed over HTTPS. The contents of such cookies are meant to be of high value and could potentially be hacked and transmitted in plain text.

Session

Session is translated as a Session. The server creates a Session object for each browser. When the browser requests the server for the first time, the server will generate a Session object for the browser, save it in the server, and send the Session Id to the client in the form of cookie to browse. The session ends when the user explicitly terminates or the session times out. When a user sends the first request to the server, the server establishes a session for that user and creates an id (sessionID) for that session. All subsequent requests from this user should include this id (sessionID). The server calibrates this id to determine which session the request belongs to.

SessionId can be used in two ways

  1. Cookie stores the sessionId
  2. The URL rewrite. After cookies are disabled on the client browser, you can use URL redirection to add the sessionID to the URL

Refer to www.cnblogs.com/xuxinstyle/…

Token

Tokens are generated on the server side. If the front end uses the user name and password to request authentication from the server, the server returns the Token to the front end. The front-end can prove its legitimacy with tokens at every request

The advantages of the Token

Tokens are fully managed by applications, so they can avoid same-origin policies tokens can avoid CSRF attacks (http://dwz.cn/7joLzx) Tokens can be stateless and can be shared across multiple servicesCopy the code

Token Expiration scheme

1. Automatic delay

  • The expiration time of the Token is automatically updated (delayed) with each operation.
  • Disadvantages: high concurrency site, frequent reads and writes, high cost.

2.Refresh Token

  • The server does not need to Refresh the expiration time of the Token. Once the Token expires, the server sends a message to the front end. The front end uses the Refresh Token to apply for a new Token. Of course, the Refresh Token has an expiration date, but the expiration date can be longer, such as 30 days.
  • Advantages: Greatly reduces the operation of updating the validity period, thus avoiding frequent reads and writes.

Stateless Token

If we attach all the state information to the Token, the server will not save. However, the server still needs to authenticate the Token. However, as long as the server can confirm that it issued the Token and that the information has not been changed, the Token is considered valid — a “signature” guarantees this. Usually, the signature is signed by one party and verified by the other party. Therefore, asymmetric encryption algorithms are used. But in this case, both issuing and authenticating are on the same side, so symmetric encryption algorithms can do the job, and symmetric algorithms are much faster (up to ten times faster) than asymmetric algorithms.

Compare Session and Token

Tokens are completely managed by applications, so they can avoid same-origin policy tokens can avoid CSRF attacksCopy the code

Why does Token protect against CSRF attacks

Cookies have an expiration time. During this time, the cookies are stored on the client. When the client visits the same website again, the browser will automatically carry the cookies after the login of the website user in the HTTP request. CSRF attacks also take advantage of this by using users’ cookies to perform operations that are not intended by users. The rule of token verification is that the server obtains the token set from the request body (POST) or request parameter (GET) and compares it with the token in the Cookie. CSRF attack only borrows Cookie and cannot obtain information in Cookie. Therefore, token in Cookie cannot be obtained. Therefore, token cannot be set in POST or GET when sending request, and when sending request to server, If token authentication fails, the request will not be processed. Therefore, token protects against CSRF attacks