Shulou(Shulou.com)06/02 Report--

Today, I will talk to you about the example analysis of CSRF (Cross-site request forgery). Many people may not understand it very well. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

SameSite Cookies

To understand the problems with CSRF and the solutions provided by SameSite Cookies, you should first read that my original blog Cross-Site Request Forgery is dead! If you want more details about cookie protection, you should also read Tough Cookies. You should take strong protection measures to protect your users / visitors, so you must turn on SameSite cookie, but it is optional. In the real world, you can enable SameSite by adding SameSite=Lax to the cookie, just like the Secure or HttpOnly tags.

As follows:

Set-Cookie: _ _ Host-session=123; path=/; Secure; HttpOnly; SameSite=Lax

But there are not many websites that add SameSite=Lax logos to their cookie.

SameSite is enabled by default

When SameSite was first introduced, no one wanted it to be the default. Because it will destroy the original things and change the expected (legacy) functionality, which will cause developers to worry about this. So the SameSite setting is optional, but that is changing.

The Mike in the figure above works on Chrome. I'm glad to see that the SameSite he mentioned will be enabled as the default setting for cookie. You can check the default setting of the Chrome platform SameSite = Lax, and you will see this in Chrome 76 (released) and later versions, and will soon log in to Chrome 78 (soon). By default, website operators do not need to provide strong protection for SameSite, but they may want everything to work as expected after using the test feature of Chrome now: chrome://flags/#same-site-by-default-cookie

More secure

As described in the link above, the site can opt out of SameSite protection if necessary or desired. To do this, the site can set SameSite=None and its Cookie,Chrome will respect the setting, but there is a requirement. Cookie must set the Secure flag! You can track the Reject insecure SameSite=None cookies status of Chrome, but it can be displayed in Chrome 76 (now) and looks set to log in to Chrome 80 later this year. The logic makes sense, and its purpose is to protect the cookie sent in cross-site requests, which can be tracked and viewed on the network, rather than sent through insecure channels such as HTTP. Similarly, website operators can use this logo to test whether it has any impact: chrome://flags/#cookies-without-same-site-must-be-secure

After reading the above, do you have any further understanding of the example analysis of the CSRF (Cross-site request forgery) problem? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.