Issues with PDF preview for secured PDF:s in Google Chrome due to .NET security patch

We had a customer that recently started to experience problems with PDF:s on an intranet where some PDFs did not load correctly in the browser. After some investigation we found that this only happened in Google Chrome – and only for larger documents. When comparing with a few other Episerver based solutions we found that the following criteria would create the issue:

1. The document had to be big enough to trigger chunked download in the browser (which happens around roughly 2 Mb in Episerver).
2. The document should not be available to everyone.
3. The solution uses Forms based authentication (with Asp.Net Identity it works as expected).

While tracking the bug – I found out that Chrome seems to handle range requests slightly differently than for instance Edge and Firefox. Also – Chrome does not show chunked requests as several requests in the browser debugger – this is only visible in a HTTP debugger tool like Fiddler. In Fiddler I could see the following behaviour:

Initial request in Chrome

Headers:
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none

Cookies: All cookies are part of the request

Subsequent requests (range download requests)

Headers:

Sec-Fetch-Site: cross-site

Cookies: Cookies that are marked as samesite = LAX are not part of these requests

When comparing some working sites with the site that had this issue – I could notice that the site with the problem had a cookie named ".EpiserverLogin" that had samesite = LAX. This cookie is the default configured name for Forms based authentication in Episerver - using Asp.Net Forms Authentication. For the working sites – the corresponding cookie with credentials is called ".AspNet.ApplicationCookie" – and this cookie did not have the corresponding samesite information. It turns out that the site with the issue uses Forms based Authentication compared to the other sites that uses Asp.Net Identity.

Since I had read a bit about the changes in Chrome related to the samesite attribute for cookies – I expected that this was the cause. However – I could experience the issue in Chrome 79 – and the changes in Chrome was first launched in version 80 that was released last week. However – I guessed that something other than Chrome did some related changes prior to the big change in Google Chrome. After some more investigation, I found that there was a security patch to .NET 3.5 and 4.7.2 that changes the samesite value for Forms authentication and Session state to LAX.

https://support.microsoft.com/sv-se/help/4533013/kb4533013-cumulative-update-for-net-framework

This patch has been rolled out in Microsoft Azure App services during January this year:
https://azure.microsoft.com/en-us/updates/app-service-samesite-cookie-update/

What do I do if I'm affected by this change?

In my opinion I think that Google Chrome treats a chunked download of a resource incorrectly by marking it as a cross site request – which causes cookies marked with LAX to be dropped from the request. I've opened a support case with Google to see if they consider this to be a bug or not. In the meantime – there are a few ways to get around the issue:

1. Specifically configure forms authentication to set samesite = None in web.config. Notice that it's strongly recommended to set this cookie as secure when doing this – which requires HTTPS to be set up – even for your developer environment.
   <authentication mode="Forms">
   <forms cookieSameSite="None" requireSSL="true" name=".EPiServerLogin" />
   </authentication>
   Information about this can be found here: https://docs.microsoft.com/en-us/aspnet/samesite/system-web-samesite
2. If this is only affecting a few PDF:s on your solution – there's a trick in Episerver to trigger the browser to download the PDF rather than opening it inside the browser. This avoids chunked download and thus the problem. This can be done by adding "/download" in the remaining URL input field in Episervers link dialog. Notice that this will affect all browsers – even browsers that does not have the issue.

More reading

Except of the links in the article - I recommend the following article to understand more about the changes in .NET related to samesite - since this has effects to other things - for instance authentication with OpenIdConnect

https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

Update 1: There already seems to be a bug report in Chromium regarding this bug - though it has not been prioritized yet. See https://bugs.chromium.org/p/chromium/issues/detail?id=961617