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

来源:https://www.cnblogs.com/holdengong/archive/2020/03/29/12591645.html

首先,好消息是Goole將於2020年2月份發佈Chrome 80版本。本次發佈將推進Google的“漸進改良Cookie”策略,打造一個更為安全和保障用戶隱私的網路環境。 壞消息是,本次更新可能導致瀏覽器無法向服務端發送Cookie。如果你有多個不同功能變數名稱的應用,部分用戶很有可能出現會話時常被打斷的 ...


首先,好消息是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/


您的分享是我們最大的動力!

更多相關文章
  • 一、背景 一方面,有時必須從幾個類中派生出一個子類,繼承它們所有的屬性和方法。但是,Java不支持多重繼承。有了介面,就可以得到多重繼承的效果。 另一方面,有時必須從幾個類中抽取出一些共同的行為特征,而它們之間又沒有is-a的關係,僅僅是具有相同的行為特征而已。 二、圖示 三、介面的使用 1.介面: ...
  • 隨著繼承層次中一個個新子類的定義,類變得越來越具體,而父類則更一般,更通用。類的設計應該保證父類和子類能夠共用特征。有時將一個父類設計得非常抽象,以至於它沒有具體的實例,這樣的類叫做抽象類。 舉例: public class test { public static void main(String ...
  • 發現按照教程操作破解Eplan,破解一直不成功。主要原因是MultiKey64在win10上運行不成功。可以通過設備管理看到是否有下圖的驅動 需要關閉win10的簽名認證,這個鏈接就是關閉的方法https://jingyan.baidu.com/article/624e74594dbc8d34e8b ...
  • 你需要瞭解的 HTTP Status Code Intro 現在前後端分離的開發模式越來越流行,後端負責開發對應的 API,前端只需要 關註前端頁面的數據展示和前端邏輯即可。 對於前後端分離這種開發模式,我個人還是比較喜歡的,因為這樣可以讓更專業的人做更專業的事情,後端專註於做 API 的開發設計, ...
  • 在ASP.NET MVC中有四種過濾器類型 Action 1、在ASP.NET MVC項目中,新建文件夾Filter,然後新建類MyCustormFilter,繼承自ActionFilterAttribute類,我們來看下ActionFilterAttribute類有如下四個方法,從命名我應該就可以 ...
  • 面向對象 面向對象是一個抽象的概念,其本質就是對事物以抽象的方式建立對應的模型。 簡單來講,比如我有一隻鋼筆,那麼我就可以通過分析,可以得到 這隻鋼筆的材第是塑料,品牌是個雜牌 ,裡面裝的墨是黑色的,可以用。這時候就能建立一個鋼筆的模型,它在這裡應該有這些屬性: 圖是一個不正確的UML類圖,但是可以 ...
  • 在上一篇abp(net core)+easyui+efcore實現倉儲管理系統——入庫管理之五(四十一) 文章中實現了入庫管理的列表頁面,並實現了控制器的代碼。在今天我們學習如何在前端實現新增入庫單信息界面。 ...
  • 在偶然一次調試某程式時,遇到提示: 無法載入程式集*****.XmlSerializers.dll,文件找不到(Could not load file or assembly ****.XmlSerializers.dll , FileNotFoundException...)。於是嘗試在項目屬性中 ...
一周排行
  • 一:背景 1. 講故事 如果你常翻看FCL的源碼,你會發現這裡面有不少方法藉助了C/C++的力量讓C#更快更強悍,如下所示: [DllImport("QCall", CharSet = CharSet.Unicode)] [SecurityCritical] [SuppressUnmanagedCo ...
  • 上一篇(https://www.cnblogs.com/meowv/p/12966092.html)文章使用AutoMapper來處理對象與對象之間的映射關係,本篇主要圍繞定時任務和數據抓取相關的知識點並結合實際應用,在定時任務中迴圈處理爬蟲任務抓取數據。 開始之前可以刪掉之前測試用的幾個Hello ...
  • 首先創建實體類 1 public class MacState 2 { 3 /// <summary> 4 /// 請求狀態 5 /// </summary> 6 public string success { get; set; } 7 /// <summary> 8 /// 錯誤信息 9 /// ...
  • 0. 前言 前幾天FreeSql的作者向我推薦了FreeSql框架,想讓我幫忙寫個文章介紹一下。嗯,想不到我也能帶個貨了。哈哈,開個玩笑~看了下覺得設計的挺有意思的,所以就謝了這篇文章。 簡單介紹一下,FreeSql 是NCC組織的沙盒級項目,是一款功能強大的 ORM 組件,支持 .NET Core ...
  • 0. 前言 這是一個新的系列,名字是《ASP.NET Core 入門到實戰》。這個系列主講ASP.NET Core MVC,輔助一些前端的基礎知識(能用來實現我們需要的即可,並非主講)。同時這個系列也會在後續介紹ASP.NET Core 平臺的其它類型的項目,並帶領大家以各個類型的項目為主要架構開發 ...
  • 我寫了一個Winform測試程式,用的System.Timers.Timer,在事件里,設置label1.Text,然後,居然句柄泄漏、用戶對象泄漏! 百思不得其解,最後換成System.Windows.Forms.Timer,居然不泄漏了! 最近睡眠不足,哪怕一個很小的問題,隨便搞搞,都半夜了! ...
  • leetcode-7. 整數反轉。 給出一個 32 位的有符號整數,你需要將這個整數中每位上的數字進行反轉。 示例 1: 輸入: 123 輸出: 321 示例 2: 輸入: -123 輸出: -321 示例 3: 輸入: 120 輸出: 21 註意: 假設環境只能存儲得下 32 位的有符號整數,則其 ...
  • 1. Java 虛擬機是什麼? 1.1 虛擬機 虛擬機:虛擬的電腦,一個用來執行虛擬電腦指令的軟體。 虛擬機分為系統虛擬機和程式虛擬機。 系統虛擬機:提供一個可運行完整操作系統的軟體平臺,如 Visual Box、VMware。 程式虛擬機:專門執行單個程式的,典型代表 Java 虛擬機。Jav ...
  • 前言 - strlen 概述 無意間掃到 glibc strlen.c 中代碼, 久久不能忘懷. 在一無所知的編程生涯中又記起點點滴滴: 編程可不是兒戲 ❀, 有些難, 也有些不捨. 隨軌跡一同重溫, 曾經最熟悉的 strlen 手感吧 ~ /* Copyright (C) 1991-2020 Fr ...
  • 背景 隊列[Queue]:是一種限定僅在表頭進行刪除操作,僅在表尾進行插入操作的線性表;即先進先出(FIFO-first in first out):最先插入的元素最先出來。 本文通過編碼實現鏈式隊列類,並模擬一個有趣的應用,能夠幫助我們對鏈式隊列有更深度的理解。 基本概念 結點 每個元素,除了存儲 ...