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

This article focuses on "analyzing Cookie SameSite attributes and their applications in ASP.NET projects". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "analyzing Cookie SameSite attributes and their applications in ASP.NET projects".

1. Introduction of Cookie SameSite attribute

As you already know, once Cookie is set, the browser will send the Cookie back to the server in all subsequent requests until the Cookie expires. Our system will use the Cookie feature to do a lot of things, but usually we will store the encrypted user identity in Cookie, and verify whether the user has the right to operate according to this identity on the server side.

When sending a Cookie, browsers did not detect whether the Domain on the current address bar is the same as the domain to which the Cookie belongs. Malicious users will use this problem to cleverly design a site to induce users to click, resulting in cross-site request forgery attacks (CSRF).

To solve this problem, the Internet Engineering Task Force (IETF) proposed a draft standard for SameSite. Chrome 51 began to support this feature, but a more stringent (Lax) default setting was enabled from the Chrome 80 Stable version.

What is a cross-site request forgery attack (Cross-Site Request Forgery Attack,CSRF)

CSRF attack simply means that malicious users steal the identity of legitimate users for malicious operations through ingenious falsification of requests.

For example, you have developed a very powerful system in which certain operations are authorized to be used only after a specific person has logged in:

Yourdomain.com/snap

[Authorize ("Thanos")] [HttpPost] public ActionResult Snap () {/ dangerous, will destroy the world.}

Because the system needs to verify identity and permissions, there is no way to call this method unless a malicious user can crack the login system and log in as Thanos.

But malicious users can forge a page like the following, where malicious users can induce authorized users to click on some Button on the page by sending e-mail or through cross-site scripting attacks (XSS). If the authorized user happens to be logged in, once the button is clicked, the system will trigger the dangerous action Snap () as that user.

Malicioususer.com/fancypage

......

Of course, Microsoft ASP.NET solves this problem through AntiForgeryToken, but this is not the subject of this blog discussion.

3. SameSite attribute of Cookie

To address the security issues of Cookie mentioned above, Chrome has added a new Cookie attribute SameSite from version 51 to control whether Cookie can be transmitted across sites.

If the domain name to which Cookie belongs is inconsistent with the domain name in the browser's address bar, it is considered cross-site. In addition, your site is considered cross-site when it is embedded in a third-party site by iframe.

This property has three property values:

None

If you need to use a Cookie in any cross-site situation, you need to set the SameSite of that Cookie to None. But it should be noted that the Secure of Cookie must be set at the same time, that is, you can turn off the SameSite function only when you need to use https access. If not marked as secure, Chrome 80 and above will refuse to set this Cookie.

Set-cookie: samesite=test; path=/; secure; SameSite=None

Strict

As the name implies, this is a strict mode, that is, cross-site Cookie is not allowed under any circumstances.

This setting obviously solves the CSRF problem mentioned above. Because when visiting the malicioususer.com/fancypage page, the current domain is malicioususer.com, but the action when user clicks button to submit points to another domain, yourdomain.com, which are two different domains, and the browser will not send back the Cookie under yourdomain.com. This will greatly improve the security of our system.

But this strict mode also limits some link operations that are considered safe, such as:

You first log in to the company's HR system, assuming that the system sets the SameSite of all Cookie to strict.

You use the Web email system to receive an email asking you to go to the HR system for approval. This email comes with a link, which links directly to the approval page in the HR system.

You click on the link, but because Cookie is set to Strict mode, when you reach the approval page, the HR system does not receive any Cookie, and it will assume that you are not logged in and jump directly to the login page. When the requirements are not very strict, it can be considered that this is not the behavior we expect. Because just jumping to the page that the link points to is not like the POST operation to modify the data. This needs to be resolved through the following Lax attribute.

Lax

Lax is a slightly looser mode than Strict. If we want to allow cross-site linking to Cookie or FORM to cross-site Cookie when submitted with GET Method, we can set the SameSite of these Cookie to Lax. Lax becomes the default setting in Chrome 80. Lax not only prevents CSRF but also ensures normal cross-site links, which is suitable for most sites and can solve the problems mentioned in HR system security above.

If your site needs to be nested by iframe on a third-party site, you still need to set Cookie to None.

One thing that comes to mind here is that if your MVC Action only expects to accept the POST method, be sure to add HttpPost Attribute to avoid unexpected security problems.

IV. Browser compatibility

The following figure shows that mainstream browsers already support SameSite, although IE 11 does not support it, but after testing, I found that the Cookie itself is still not lost, only the lack of security features.

How to modify the ASP.NET program

The steps summarized below are applicable to systems developed based on ASP.NET. Microsoft's official white paper describes these attribute settings in detail, and you can also refer to the official white paper.

The .NET Framework 4.7.2 or 4.8 only started to support SameSite, and added the attribute of SameSite to HttpCookie. So you need to install the .NET Framework 4.7.2 or above SDK, and you need to install it on the development computer and server.

To install the Windows cumulative update patch on 2019-11-19, see KB Articles that support SameSite in .NET Framework, which also needs to be installed on the development computer and server. Before installing this patch, if SameSite is None, .NET Framework will not output this property to Broswer, but Chrome 80 and later will not set the default to Lax, resulting in inconsistent behavior, so you need to install this patch to explicitly output None.

Enter: chrome://flags/, in the Chrome address bar to set the following two items to Enabled. These two settings are enabled because not all Chrome enables these two settings by default, Chrome is just gradually turning them on to Chrome's user. Therefore, in order to reproduce the problem during development, it is best to open it explicitly.

Chrome://flags/#same-site-by-default-cookies

Chrome://flags/#cookies-without-same-site-must-be-secure

At this point, I believe you have a deeper understanding of "analyzing Cookie SameSite attributes and their application in ASP.NET projects". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.