Chrome80調整SameSite策略對IdentityServer4的影響以及處理方案（翻譯）

首先，好消息是Goole將於2020年2月份發佈Chrome 80版本。本次發佈將推動Google的「漸進改良Cookie」策略，打造一個更爲安全和保障用戶隱私的網絡環境。

壞消息是，本次更新可能致使瀏覽器沒法向服務端發送Cookie。若是你有多個不一樣域名的應用，部分用戶頗有可能出現會話時常被打斷的狀況。還有部分用戶可能沒法正常登出系統。

本篇博客將處理第一個問題（沒法發送cookie到服務端）。至於第二個問題（cookie沒法被刪除），請參考另外一篇博客。

首先，SameSite是什麼

互聯網是十分開放的平臺：Cookie誕生於二十多年前，於2011年修訂(RFC 6265)。當時跨站訪問攻擊（CSRF）沒有如今這麼猖獗，侵犯用戶隱私的行爲也不像如今這樣氾濫。

簡而言之，Cookie標準規範規定，若是某域名下設置了Cookie，無論你是直接跳轉到該域名，或是加載了該域名的某些資源（例如圖片），或是向該域名發送POST請求，亦或將其嵌入iframe，瀏覽器訪問該域名的每次請求，都將帶上這個Cookie。

對於iframe嵌入的場景，你可能不但願瀏覽器將用戶會話cookie自動發送到服務器，由於這樣任何其餘網站均可以在用戶不知情的狀況下，用他的會話上下文，跟你的服務器發送請求。

爲了不這種狀況，SameSite cookie規範於2016年起草。對於發送cookie咱們有了更多的控制權：如今能夠明確指定每一個cookie是否被髮送。規範引入了同站/跨站cookie的概念，若是瀏覽器訪問A域名，請求服務端也是A域名，這些cookie就叫同站cookies（same-site cookies），若是瀏覽器訪問A域名，請求服務端是B域名，這些cookie就叫跨站cookies（cross-site cookies）。

爲了向後兼容，same-site的默認設置並未改變以前的行爲。你必須手動指定SameSite=Lax或者SameSite=Strict，來能使用這項特性加固安全。全部的.NET框架和常見的瀏覽器都已支持這一特性。設置爲Lax，大多數狀況不容許發送第三方Cookie，導航到目標網址的Get請求除外。設置爲Strict，徹底禁止第三方Cookie，除非你以前訪問過該域名而Cookie已經存在於瀏覽器。

悲哀的是，這項新特性的採用率低的可憐（基於Chrome2019年3月份統計顯示，在全部的cookie中，只有0.1%使用了SameSite標誌）。

Google決定推動這項特性的使用。他們決定修改世界上最多人使用的瀏覽器——Chrome的默認設置：若是想保持以前處理cookie的方式，Chrome 80要求顯示指定SameSite=None。若是像之前同樣忽略SameSite屬性，Chrome將視做SameSite=Lax。

請注意：SameSite=None只有在Cookie同時被標記爲Secure而且使用https鏈接時纔會生效。

更新：若是你想知道關於SameSite cookies的更多背景知識，請擴展閱讀這篇文章。

這會影響我嗎？什麼影響？

若是你有一個單頁應用（SPA），使用另外一域名的認證服務（好比IdentityServer4）進行身份認證，而且使用了所謂的靜默令牌刷新的話，你將受影響。
譯者注：使用refresh_token刷新access_token,用戶無感知

登陸到認證服務的時候，它會爲當前用戶設置會話cookie，這個cookie屬於認證服務域名。認證流程結束以後，另外一域名會收到認證服務頒發的access token，有效期一般不會太長。當access token過時以後，應用沒法訪問api，用戶須要頻繁的登陸，體驗十分差。

爲了不這一狀況，咱們可使用refresh_token實現靜默刷新。應用建立一個用戶不可見的iframe，在iframe中進行新的認證流程。iframe中加載了認證服務站點，當瀏覽器發送會話cookie的時候，認證服務識別出當前用戶而後頒發新的token。

SPA網站使用iframe嵌入了認證服務站點的內容，這就是一個跨站請求，只有將iframe中屬於認證服務站點的cookie設置爲SameSite=None，Chrome 80纔會將iframe中的cookie發送到認證服務。不然，token靜默刷新將沒法正常運行。

可能還會致使一些其餘的問題：若是應用中嵌入了其餘域名的資源，好比視頻自動播放設置，它們須要cookie才能正常運行。某些依賴cookie認證來訪問第三方API的應用也會出現問題。

注意：很顯然你只能修改本身服務的cookie設置。若是使用了其餘域名的資源，這些不在你的控制範圍以內，你須要聯繫第三方修改他們的cookie設置。

好的，我會修改代碼將SameSite設置爲None的，這樣就萬事大吉了，是嗎？

很不幸，並非：Safari存在一個"bug"。這個bug致使Safari不會將None識別爲SameSite的合法值。當Safari遇到非法參數值的時候，它會將其視做SameSite=Strict，不會向認證服務發送會話cookie。IOS13和macOS 10.15 Catalina系統上的Safari 13已修復此bug，macOS 10.14 Mojave和iOS 12將不會修復，而這幾個版本依舊存在大量用戶羣。

如今咱們進退兩難：要麼忽略這次更新，Chrome用戶沒法使用靜默刷新，要麼設置SameSite=None，那麼沒法更新到最新系統的iPhone,iPad和Mac用戶的應用將出現異常。

有沒有方法明確知道本身受影響？

幸運的是，你能夠。若是你已經設置了SameSite=None，應該注意到應用在iOS 12,macOS 10.4的Safari上運行異常。若是尚未設置的話，確保要在上面版本系統的Safari上作一下測試。

若是尚未設置的話，能夠打開Chrome的開發者工具。能夠看到這些警告：

A cookie associated with a cross-site resource at {cookie domain} was set without the `SameSite` attribute.
A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`.
You can review cookies in developer tools under Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.

若是設置了SameSite=None可是沒有Secure標識，將看到以下警告：

A cookie associated with a resource at {cookie domain} was set with `SameSite=None` but without `Secure`.
A future release of Chrome will only deliver cookies marked `SameSite=None` if they are also marked `Secure`.
You can review cookies in developer tools under Application>Storage>Cookies and
see more details at https://www.chromestatus.com/feature/5633521622188032.

怎樣才能修復這個問題？我須要Chrome和Safari都能正常運行。

我和個人同事Boris Wilhelms作了一些研究和驗證，找到了一個解決方案。微軟的Barry Dorrans寫了一篇很不錯的博客能夠參考。這個解決方案並非完美之策，它須要在服務端嗅探瀏覽器類型，可是它很簡單，在過去幾周，咱們已經用這個方案修復了數個項目。

首先咱們須要確保須要經過跨站請求發送的cookie - 好比會話cookie - 被設置爲SameSite=None而且標識爲Secure。咱們須要在項目中找到Cookie選項配置代碼，而後作出調整。這樣Chrome的問題修復了，而後Safari會出現問題。

而後咱們須要將下面的類和代碼段加到項目中。這段代碼在ASP.NET Core應用中配置了一個cookie策略。這個策略會檢查cookie是否應該被設置位SameSite=None。

請注意：這個解決方案是.NET Core使用的。至於.NET Framework項目，請查看Barry Dorran的這篇博客。

將這個類加到項目中

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
 
namespace Microsoft.Extensions.DependencyInjection
{
   public static class SameSiteCookiesServiceCollectionExtensions
   {
      /// <summary>
      /// -1 defines the unspecified value, which tells ASPNET Core to NOT
      /// send the SameSite attribute. With ASPNET Core 3.1 the
      /// <seealso cref="SameSiteMode" /> enum will have a definition for
      /// Unspecified.
      /// </summary>
      private const SameSiteMode Unspecified = (SameSiteMode) (-1);
 
      /// <summary>
      /// Configures a cookie policy to properly set the SameSite attribute
      /// for Browsers that handle unknown values as Strict. Ensure that you
      /// add the <seealso cref="Microsoft.AspNetCore.CookiePolicy.CookiePolicyMiddleware" />
      /// into the pipeline before sending any cookies!
      /// </summary>
      /// <remarks>
      /// Minimum ASPNET Core Version required for this code:
      ///   - 2.1.14
      ///   - 2.2.8
      ///   - 3.0.1
      ///   - 3.1.0-preview1
      /// Starting with version 80 of Chrome (to be released in February 2020)
      /// cookies with NO SameSite attribute are treated as SameSite=Lax.
      /// In order to always get the cookies send they need to be set to
      /// SameSite=None. But since the current standard only defines Lax and
      /// Strict as valid values there are some browsers that treat invalid
      /// values as SameSite=Strict. We therefore need to check the browser
      /// and either send SameSite=None or prevent the sending of SameSite=None.
      /// Relevant links:
      /// - https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-4.1
      /// - https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
      /// - https://www.chromium.org/updates/same-site
      /// - https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
      /// - https://bugs.webkit.org/show_bug.cgi?id=198181
      /// </remarks>
      /// <param name="services">The service collection to register <see cref="CookiePolicyOptions" /> into.</param>
      /// <returns>The modified <see cref="IServiceCollection" />.</returns>
      public static IServiceCollection ConfigureNonBreakingSameSiteCookies(this IServiceCollection services)
      {
         services.Configure<CookiePolicyOptions>(options =>
         {
            options.MinimumSameSitePolicy = Unspecified;
            options.OnAppendCookie = cookieContext =>
               CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
            options.OnDeleteCookie = cookieContext =>
               CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
         });
 
         return services;
      }

      private static void CheckSameSite(HttpContext httpContext, CookieOptions options)
      {
         if (options.SameSite == SameSiteMode.None)
         {
            var userAgent = httpContext.Request.Headers["User-Agent"].ToString();

            if (DisallowsSameSiteNone(userAgent))
            {
               options.SameSite = Unspecified;
            }
         }
      }
 
      /// <summary>
      /// Checks if the UserAgent is known to interpret an unknown value as Strict.
      /// For those the <see cref="CookieOptions.SameSite" /> property should be
      /// set to <see cref="Unspecified" />.
      /// </summary>
      /// <remarks>
      /// This code is taken from Microsoft:
      /// https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
      /// </remarks>
      /// <param name="userAgent">The user agent string to check.</param>
      /// <returns>Whether the specified user agent (browser) accepts SameSite=None or not.</returns>
      private static bool DisallowsSameSiteNone(string userAgent)
      {
         // Cover all iOS based browsers here. This includes:
         //   - Safari on iOS 12 for iPhone, iPod Touch, iPad
         //   - WkWebview on iOS 12 for iPhone, iPod Touch, iPad
         //   - Chrome on iOS 12 for iPhone, iPod Touch, iPad
         // All of which are broken by SameSite=None, because they use the
         // iOS networking stack.
         // Notes from Thinktecture:
         // Regarding https://caniuse.com/#search=samesite iOS versions lower
         // than 12 are not supporting SameSite at all. Starting with version 13
         // unknown values are NOT treated as strict anymore. Therefore we only
         // need to check version 12.
         if (userAgent.Contains("CPU iPhone OS 12")
            || userAgent.Contains("iPad; CPU OS 12"))
         {
            return true;
         }

         // Cover Mac OS X based browsers that use the Mac OS networking stack.
         // This includes:
         //   - Safari on Mac OS X.
         // This does not include:
         //   - Chrome on Mac OS X
         // because they do not use the Mac OS networking stack.
         // Notes from Thinktecture: 
         // Regarding https://caniuse.com/#search=samesite MacOS X versions lower
         // than 10.14 are not supporting SameSite at all. Starting with version
         // 10.15 unknown values are NOT treated as strict anymore. Therefore we
         // only need to check version 10.14.
         if (userAgent.Contains("Safari")
            && userAgent.Contains("Macintosh; Intel Mac OS X 10_14")
            && userAgent.Contains("Version/"))
         {
            return true;
         }

         // Cover Chrome 50-69, because some versions are broken by SameSite=None
         // and none in this range require it.
         // Note: this covers some pre-Chromium Edge versions,
         // but pre-Chromium Edge does not require SameSite=None.
         // Notes from Thinktecture:
         // We can not validate this assumption, but we trust Microsofts
         // evaluation. And overall not sending a SameSite value equals to the same
         // behavior as SameSite=None for these old versions anyways.
         if (userAgent.Contains("Chrome/5") || userAgent.Contains("Chrome/6"))
         {
            return true;
         }

         return false;
      }
   }
}

配置並啓用cookie策略

在Starup中加入下面的代碼，使用cookie策略

public void ConfigureServices(IServiceCollection services)
{
   // Add this
   services.ConfigureNonBreakingSameSiteCookies();
}
 
public void Configure(IApplicationBuilder app)
{
   // Add this before any other middleware that might write cookies
   app.UseCookiePolicy();

   // This will write cookies, so make sure it's after the cookie policy
   app.UseAuthentication();
}

Ok，完事了嗎？

還須要作全面的測試，特別是Chrome79，以及受影響的Safari版本。
檢查一下你的靜默token刷新，還有須要cookie的跨站請求，是否正常工做。
這些都沒問題就完事了。

能夠等IdentityServer4修復這個問題嗎？

不太可能。並非IdentityServer在管理這些cookie。IdentityServer依賴於ASP.NET Core框架內置的認證系統，它們在管理會話cookie。然而微軟表示它們不能使用在ASP.NET Core直接嗅探瀏覽器版本的方案。因此基本上短時間內只能靠本身了。

總結

Chrome於2020年2月發佈的新版本修改了cookie的默認行爲。新版本須要SameSite明確設置爲None，同時有Secure標識，纔會將該cookie發送到跨站請求。若是你這麼作的話，不少版本的Safari會出現問題。

爲了確保應用在全部瀏覽器運行正常，咱們將全部受影響的cookie設置爲Secure，SameSite=None，而後新增一個Cookie策略，根據瀏覽器版本動態處理SameSite設置。

譯者注

文中提到的方案須要設置SameSiteMode=-1，這個新增長的枚舉，須要更新微軟相補丁包，.net core2.1因爲是長期維護版本微軟提供了補丁包，.net core 3.x也已經支持。若是是2.2或者其餘再也不維護的版本，可能須要升級到3.x。詳情見下面的博客。
https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

原文地址：https://www.thinktecture.com/en/identity/samesite/prepare-your-identityserver/