SameSite cookie updates in ASP.net, or how the .Net Framework from December changed my cookie usage.

The Internet is a constantly changing place, and the standards that govern it change as well. This week, on February 4^th, one of those standards (actually a draft) will be replaced by a new draft (which is implemented by Chrome version 80) and other browsers that are soon to follow. This is the SameSite draft standard that has been around since 2016 and has gotten a major update last year. So why should you care and why are there updates from .Net Framework to change the way cookies are managed?

Third party cookies:

To answer these questions we must start at the beginning by making the difference between first and third party Http Cookies. Http Cookies are server headers comprised of a ‘Set Cookie’ header name and name value pairs in the body of the header that the Http server sends to the client along with responses to requests. The information is stored by the client (the browser) and is retransmitted to the server on each subsequent request. Here is what a session cookie from ASP.net looks like when it is received from the server:

HTTP/1.1 200 OK
Cache-Control private
Content-Encoding    gzip
Content-Length      5536
Content-Type text/html; charset=utf-8
Date   Tue, 04 Feb 2020 16:36:28 GMT
Server Microsoft-IIS/10.0
Set-Cookie   ASP.NET_SessionId=2qvabe5nwvvunf1ihxp2gvwo; path=/; secure; HttpOnly; SameSite=Lax
Vary   Accept-Encoding
X-AspNet-Version    4.0.30319
X-Powered-By ASP.NET

A cookie can have many attributes to instruct the browser on how long it should be kept for, which parts of your website to send it back to, if to only send it back via a secure connection, etc. In the example above, the cookie is value for all paths inside my website (determined by the path=/ attribute), it should only be sent over Https connections (indicated by the ‘secure’) attribute, and so on.

Cookies are normally sent back by the browser to the website (and domain) that they were received from. If you have visited Microsoft.com your browser will send cookies received from Microsoft.com back to the servers hosting Microsoft.com and will not send these cookies to other sites, such as Facebook.com, Twitter.com etc…. But what happens when you have a website that uses resources that are also coming from other sites? Suppose the following setup: my home page for my website (www.linqto.me) uses a background image from www.backgrounds.com. In order to load the page, my browser will be making requests to both the www.linqto.me server and the www.backgrounds.com server as shown in the image below:

Assuming that I have also visited www.backgrounds.com to check out their site, my browser will have cookies from both www.linqto.me and www.backgrounds.com . When I load my home page from www.linqto.me, the browser will be sending the cookies from www.linqto.me to the hosting webserver, but since the image of the background is located on www.backgrounds.com it will also be sending the cookies from www.backgrounds.com along with the request for the image.

In this example, the cookies sent with the green request (to www.backgrounds.com) are considered third party cookies, since they are not for the site that I have typed in the address bar of my web-browser.

SameSite specification.

In order to help manage when third party cookies should or should not be sent, depending on the situation, a new attribute was added to the Http Cookie specification. This attribute is the SameSite attribute and originally, it had two values: Lax and Strict.

Lax – meant that the cookie should be sent in some third-party scenarios (and I will come back to which in a minute)
Strict – meant that the cookie should only be sent back when it was not considered a third-party cookie.
Cookies with no attribute (missing the SameSite attribute all together) were treated as cookies that could be sent back by the browser in any scenario.

In the example above, if the request for www.backgrounds.com had set a cookie with an attribute of SameSite=Strict, the browser should not have sent the cookie back when loading the page for www.linqto.me, since here the cookie would have been considered a third party cookie.

At this point you may be wondering if all domains and host names inside domains are considered different? Are www.linqto.me and blog.linqto.me two different sites or are they the same site? And the answer is that they are considered to be the same site. In general, all host names for a domain will be considered as being the SameSite, with some service exceptions. A good example is Blogspot.com – when you create a blog on BlogSpot, you will receive a blog url that looks like yourcoolblog.blogspot.com. This will be different from another BlogSpot url like pocketdiarybudapest.blogspot.com. Hence a login cookie from YourCoolBlog.blogspot.com will not be sent to PocketdiaryBudaptest.blogspot.com since they are not considered to be the same site.

The list of services that work this way are detailed here: https://publicsuffix.org/list/ - look for the declaration of services with the TLD (Top Level Domains)

When can a cookie marked as Lax be sent as a third-party cookie? The table below shows this:

Also note that cookies with no SameSite attribute present (marked with <None> in the table) will be sent along with any of the requests above, even if these requests are made to third party sites, and hence the cookies are considered third party cookies.

New SameSite specification:

The issue with the old specification that came out in 2016 is that by default cookies do not have any SameSite attribute, and that these cookies are treated just like before the specification was published. This is not very good for cross site tracking and cross site requests in general. The new standard aims to change that by doing two things:

1. It introduces a new value for the SameSite attribute: None.
2. It changes the default norm: cookies with no SameSite attribute will now be considered to implicitly behave just like cookies with the SameSite attribute set to ‘Lax’.

Point number 2 in the above list is very important: this changes the way that cookies will be sent by the browser: before if the cookie did not have a SameSite attribute, it would be sent along with all requests, whereas now, it will abide by the same rules as the Lax attribute imposes (and that are listed in the table above).

This also creates a problem, since, although being inherently more secure, some older browses are not aware of the new value for the SameSite attribute – the value ‘None’. The version of the specification that was written in 2016 indicated that if the SameSite attribute had an unknown value, it should be considered the same as ‘Strict’ – which is the opposite of SameSite=None.

Some of the older browsers around on the web, notably Chrome versions 50 through 60, and Safari on IOS 12, will consider a cookie marked with SameSite=None to be SameSite=Strict and behave accordingly. This is why, some sites will have to alter their code and detect which browser we are dealing with and then emit the cookie with or without a SameSite=None attribute accordingly. Note that this is the only case where conditional rendering would have to be applied to transition from the old to the new specification.

.Net Framework roll-ups from November / December 2019

To anticipate the upcoming implementation of the SameSite specification, the .Net Framework team has released updates to the .Net Framework 4.7.2 and 4.8 that will mark all Session and Authentication cookies that do not have a SameSite attribute present as being SameSite=Lax. This helps do away with the implicit consideration of cookies with no SameSite attribute as being the same as cookies marked as SameSite=Lax. Note that all cookies that are generated by the application, and are not session related or Authentication related remain unchanged. We will review later how to change the behavior to have a SameSite attribute explicitly emitted for these cookies as well.

The roll-ups for the .Net Framework have come out at the end of November, and the start of December 2019 (depending on the operating system we are targeting). The chart below aims to show the release dates:

All roll-ups of the .Net Framework 4.7.2 and 4.8 after these dates will contain the cumulative updates included in the November / December 2019 timeframe. Therefore, a website that is running on an updated version of the .Net Framework will immediately start emitting cookies with the SameSite attribute set to ‘Lax’ whereas no SameSite attribute was present before.

!One more thing: updating to .Net Framework 4.8?

If you are upgrading your .Net Framework installation from 4.7.2 to 4.8 be very careful. The installer for .Net Framework 4.8 brings in the RTM version of the framework, which does not contain the new specification changes for the SameSite attribute. You will need to perform the updates for the .Net Framework to bring it up to at least the updates from December 2019 before this functionality will be present.

In the next installment, we take a look at what scenarios this change will impact sites and what you (as a website owner) can do to become compliant.

Written by: Paul Cociuba