Summary of discussion on nginx cookie validity period

Every visit will generate Cookie in the browser, so is the existence of Cookie good or bad for users? To be honest, the existence of this thing does bring a series of problems. The interesting thing is that almost every site is difficult to leave Cookie . The use of Cookie is easily underestimated because of its seemingly simple appearance. Recently, during the development process, I reviewed the Cookie code in the application and found that it only takes a small price to get huge security benefits. So write this note to deepen your memory.

Security risks of cookies

In actual application scenarios, the most common thing Cookie is used for is to maintain the server status of identity authentication. This retention may be session Session based or persistent. However, no matter which one, once the server Ticket contained in the authentication Cookie is leaked, it will be difficult for the server to distinguish whether the user request with this ticket comes from a real user or from a malicious attacker.

In actual cases, the most common way to cause Cookie leakage is through cross-site scripting (such as XSS, Cross Site Script) vulnerabilities. An attacker can steal important Cookie identifiers that represent user identities through a small piece of JavaScript code. Since cross-site scripting vulnerabilities are so common (don’t think that simple HTML Encode can avoid cross-site scripting, cross-site scripting is a very profound subject, so much so that a special term has been derived in the industry: cross-site scripting), almost every website cannot avoid it, so this method is a commonly used means in practice .

In fact, the first secret to avoiding this problem is to do everything possible to tag your Cookie with HttpOnly . The specific use of HttpOnly is beyond the scope of this article.

How Cookies Work

When you visit a website for the first time, the browser sends a request. After the server responds to the request, it will put Cookie into the response request. When the browser sends a second request, it will bring Cookie over. The server will identify the user. Of course, the server can also modify Cookie content.

Cookie Lifecycle

When creating Cookie , a value is assigned to Cookie : Expire , which specifies the validity period of Cookie , that is, the life cycle of Cookie . If the set life cycle is exceeded, Cookie will be cleared. If you set the Expire value to 0 or a negative value, the Cookie will be cleared when you close the browser, which is a safer approach.

Modify cookie validity period

Normally, our web application services are published through nginx . At this time, we can change the validity period of cookie by modifying the configuration file on nginx . Since the author has recently been developing functions for nginx based on openresty . It is a good opportunity to test the validity period of Cookie .

As mentioned above in the life cycle of Cookie , in order to ensure the security of the validity period, we can set a reasonable validity period for Cookie . If it is 0 or a negative value, what is the effect? Take a look

Modification ideas

Use Openresty 's resty.cookie to modify it. This library is used to operate HTTP cookie on OpenResty . Can be used to parse HTTP Cookie header for Nginx and return each field in Cookie . For example, set name , value , httponly and other attributes

Valid for 24 hours

Here, expires is set to a validity period of one day (24h) , which is the current system time (ngx.time()) plus 24 hours.

 local cookie = resty_cookie:new()

 local ok, err = cookie:set({
  key = "middle_session",
  value = session,
  path = "/",
  secure = false,
  httponly = true,
  expires = ngx.cookie_time(ngx.time() + 60 * 60 * 24),
  domain = ngx.host,
 })

Effect

Here you can see that the validity period of our cookie is 14:04 on May 13, which means that our modified configuration is effective and we can modify Cookie through this parameter. As long as this time point is reached, the Cookie will become invalid and the user will need to log in again.

Valid for Genesis

Here, expires is set to -1. It can be observed that the cookie is used in 1970, which is the meta-time of the UNIX era.

 local cookie = resty_cookie:new()

 local ok, err = cookie:set({
  key = "middle_session",
  value = session,
  path = "/",
  secure = false,
  httponly = true,
  expires = ngx.cookie_time(-1),
  domain = ngx.host,
 })

From the figure below, you can see that Cookie is valid until January 1, 1970, which is undoubtedly outdated at this point in time. Of course, this is the configuration in the production environment. You will be locked up in a small dark room to discuss the value of life. Users will not be able to log in successfully no matter what if they encounter such Cookie configuration.

Valid until current

Because ngx.cookie_time returns a formatted string that can be used as Cookie expiration time, we manually specify the expiration time ourselves. This method can be used to test the effect of automatic Cookie clearing mentioned above.

Specify an expiration time of -1

 local cookie = resty_cookie:new()

 local ok, err = cookie:set({
  key = "middle_session",
  value = session,
  path = "/",
  secure = false,
  httponly = true,
  expires = -1,
  domain = ngx.host,
 })

Specify an expiration time of 0

 local cookie = resty_cookie:new()

 local ok, err = cookie:set({
  key = "middle_session",
  value = session,
  path = "/",
  secure = false,
  httponly = true,
  expires = 0,
  domain = ngx.host,
 }) 

in conclusion

Configuring -1 and 0 here is the same as configuring meta time in practical terms, but the advantage is that you don't have to be locked up in a dark room. Cookie is only valid on the current page. Once the browser is closed, the Cookie will be cleared by the browser. At this time, there is no need to worry about security issues.

Reference Documents:

Cookie security talkhttps://www.infoq.cn/article/cookie-security

Let's talk about cookies clearly https://juejin.im/post/59d1f59bf265da06700b0934

A brief discussion on cookie security https://zhuanlan.zhihu.com/p/58666986

This concludes this article on the discussion summary of nginx cookie validity period. For more relevant content on nginx cookie validity period, please search 123WORDPRESS.COM’s previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!