Security risks that cookies may encounter

What is a cookie

First, a cookie is a string that is stored in the browser on the front end. It has a tiny 4k capacity. As HTTP protocol is a stateless protocol, communication requires an identity certificate, and this certificate is written in cookie, which is the most commonly used cookie.

Cookie is the data sent by the back end by setting HTTP headers to achieve data writing cookie. When the browser requests, it will bring the cookies that meet the requirements to the server for verification. Of course, the front end can also operate cookies, but the purpose of the front end to operate cookies is generally to read cookies and process some parameters or read parameters in some business scenarios, put parameters in POST and then request some interfaces, The front end basically doesn’t modify the cookie content set by the server.

The following is a cookie interaction flow:

After the browser requests web login and completes identity authentication, the server returns a cookie and stores it in the browser. The browser will carry the cookie with it the next time it accesses the web.

The characteristics of the cookie

A cookie contains information such as domain name, expiration date, path, HTTP-only, Secure, and Samesite (Google Chome).

The domain name

Cookies follow the same origin policy rules, so cookies are valid only in the same domain. In our daily development, a Web may have different domains, but most of them are the same. For example, for the projects of m.ke.qq.com and M.bc.qq.com, we can set the domain name of cookie under the domain name of QQ.com. This allows both sites to read the login status information. Of course, this is just an example, usually not set in the qq.com domain, because there are too many web in this domain.

The difference between domains is mostly in the environment, such as the development environment and the test environment. If the internal deployment environment is referenced, the two domain names are often different from the online one, which requires the backend to add the login information under the domain name separately.

The period of validity

The expire parameter of cookies is expire. There are also two methods. The first method is to write to the session, which is valid for the duration of the browser session. The other is to convert the date object to a string and then write the cookie.

let date = new Date(a);let exprie = data.toGMTString();
document.cookie = `exprie=${exprie}`;
Copy the code

There is no separate method to delete cookies. Its deletion method is to set the validity period to an expiration time.

The path

The Path parameter is Path, which means that the cookie can be used only if the Path is specified. In this case, the cookie is set to \, which can be used in the current directory, because it can be used in any current domain.

http-only

The http-only key is HttpOnly, which means it can be used only in HTTP requests.

secure

Secure Key is secure, which means it can be used only with HTTPS requests.

The role of cookies and possible security problems

Tamper with the problems

The biggest function of cookies is to store user login information, which can be divided into two types. The first type is the front-end storage of user related information, such as user ID. The other is that the backend stores the user’s relevant login information and then generates an ID to send to the browser.

The first case: the user ID is stored in a cookie. After the user logs in, the server sends the user ID and writes it into the cookie of the browser. The next request is returned to the server. There is a security risk, that is, artificially changing the user ID has been planted, if the ID is changed at the same time the server does not do other checks just match the user ID, it will cause security problems, because then others can arbitrarily various operations.

The solution is to set a token generated according to the user ID at the same time as the user ID. Bring it back together the next time you request the server. The server decrypts the token in the request and finally determines whether to solve the parameter ID. If yes, it indicates that the login state is correct. If not, it directly intercepts the operation.

His principle is that the server has its own key, others can not understand what the meaning of the ID set by cookie is, only with the key of the server to unlock the data before encryption.

Take a look at a specific example. For example, in the web QQ login state, you can see that there are two parameters in the cookie, one is open_id and the other is access_token.

What does not need token processing for ID is some business logic. For example, I developed a shopping cart component earlier, in which the selected shopping elements are cached locally according to the ID of the shopping cart. It doesn’t really matter if these elements are changed, because the background is going to check the product ID, and even if you change the other one, you still have to pay, so it doesn’t really matter.

In the second case, the user’s login information is stored on the server and then an ID is generated and sent to the browser. This ID has no information, just an ID. But this ID is sent to the background along with the request, and the background uses this ID to find out who the user is.

Despite this way, but I handle project using this method, but no one is because here for the server side has a performance problem, if the user volume is very big, the server will need to store a lot of id data, and, if the user login in multiple places at the same time, if it is to do different judgments. Therefore, this method should not be used frequently.

The effect is as follows:

Exploited information and theft

XSS and CSRF are the problems of stealing and directly using cookies respectively, and the means of protection have been explained in the previous chapters. You can refer to the articles of the previous two periods:

  • CSRF injection (CSRF
  • XSS injection diagram for WEB Security (I

The security policy

To clarify, the security method for cookies is as follows:

  • To prevent tampering
  • The background of encryption
  • HTTP – only configuration
  • Secure configuration

Background encrypted means to give the fuzzy information processing, he and prevent tampering with a little different, is to prevent tampering with the data transfer is still clear just added a token parsing validation process, and the background is the fuzzy information encryption, is others can’t understand the content of information, only to the server according to the rules of their analytical know what it is.

Secure prevents some eavesdropping.

These are the cookie-related security policies.