SameSite ist eine 2016er
Erweiterung für HTTP-Cookies , mit denen die Fälschung von Cross Site Request (CSRF) verringert werden soll. Das ursprüngliche Design war eine Opt-In-Funktion, die durch Hinzufügen einer neuen SameSite-Eigenschaft zu Cookies verwendet werden konnte. Es hatte zwei Werte, Lax und Strict.
Wenn Sie den Wert auf Lax setzen, wird angegeben, dass das Cookie bei der Navigation innerhalb derselben Site oder über die GET-Navigation von anderen Sites zu Ihrer Site gesendet werden soll. Ein Wert von Strict beschränkte das Cookie auf Anforderungen, die nur von derselben Site stammten. Wenn Sie die Eigenschaft überhaupt nicht festlegen, wird der Fluss des Cookies in Anforderungen nicht eingeschränkt. OpenIdConnect-Authentifizierungsvorgänge (z. B. Anmelden, Abmelden) und andere Funktionen, die POST-Anforderungen von einer externen Site an die Site senden, die den Vorgang anfordert, können Cookies für den Korrelations- und / oder CSRF-Schutz verwenden. Diese Vorgänge müssten SameSite deaktivieren, indem die Eigenschaft überhaupt nicht festgelegt wird, um sicherzustellen, dass diese Cookies während ihrer speziellen Anforderungsflüsse gesendet werden.
Google
aktualisiert jetzt
den Standard und implementiert die vorgeschlagenen Änderungen in einer kommenden Version von Chrome. Durch die Änderung wird der neue SameSite-Wert "Keine" hinzugefügt und das Standardverhalten in "Lax" geändert. Dadurch werden OpenIdConnect-Anmeldungen und möglicherweise andere Funktionen, auf die Ihre Website angewiesen ist, unterbrochen. Diese Funktionen müssen Cookies verwenden, deren SameSite-Eigenschaft auf den Wert "Keine" festgelegt ist.
Browser, die dem ursprünglichen Standard entsprechen und den neuen Wert nicht kennen, verhalten sich jedoch anders als Browser, die den neuen Standard als SameSite-Standard verwenden. Wenn ein Browser einen Wert für SameSite sieht, versteht er nicht, dass er diesen Wert als behandeln sollte "Streng." Dies bedeutet, dass Ihre .NET-Website jetzt Benutzeragenten-Sniffing hinzufügen muss, um zu entscheiden, ob Sie den neuen Wert None senden oder das Attribut überhaupt nicht senden.
.NET wird Aktualisierungen herausgeben, um das Verhalten seines SameSite-Attributs in .NET 4.7.2 und in .NET Core 2.1 und höher zu ändern, um die Einführung eines neuen Werts durch Google widerzuspiegeln. Die Updates für .NET Framework werden am 19. November als optionales Update über Microsoft Update und WSUS verfügbar sein, wenn Sie die Funktion "Nach Updates suchen" verwenden. Am 10. Dezember wird es allgemein verfügbar sein und in Microsoft Update angezeigt, ohne dass Sie speziell nach Updates suchen müssen. .NET Core-Updates werden mit .NET Core 3.1 ab Vorschau 1 im November verfügbar sein.
.NET Core 3.1 enthält die
aktualisierte Aufzählungsdefinition SameSite.Unspecified, mit der die SameSite-Eigenschaft nicht festgelegt wird.
Die OpenIdConnect-Middleware für Microsoft.Owin v4.1 und .NET Core wird gleichzeitig mit den .NET Framework- und .NET-Updates aktualisiert. Wir können jedoch den Sniffing-Code für Benutzeragenten nicht in das Framework einführen. Dies muss in Ihrem implementiert werden Site-Code. Die Implementierung von Agent-Sniffing hängt davon ab, welche Version von ASP.NET oder ASP.NET Core Sie verwenden und welche Browser Sie unterstützen möchten.
Für ASP.NET 4.7.2 mit Microsoft.Owin 4.1.0 kann das Agenten-Sniffing mit
ICookieManager implementiert werden.
public class SameSiteCookieManager : ICookieManager { private readonly ICookieManager _innerManager; public SameSiteCookieManager() : this(new CookieManager()) { } public SameSiteCookieManager(ICookieManager innerManager) { _innerManager = innerManager; } public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { CheckSameSite(context, options); _innerManager.AppendResponseCookie(context, key, value, options); } public void DeleteCookie(IOwinContext context, string key, CookieOptions options) { CheckSameSite(context, options); _innerManager.DeleteCookie(context, key, options); } public string GetRequestCookie(IOwinContext context, string key) { return _innerManager.GetRequestCookie(context, key); } private void CheckSameSite(IOwinContext context, CookieOptions options) { if (DisallowsSameSiteNone(context) && options.SameSite == SameSiteMode.None) { options.SameSite = null; } } public static bool DisallowsSameSiteNone(IOwinContext context) { // TODO: Use your User Agent library of choice here. var userAgent = context.Request.Headers["User-Agent"]; return userAgent.Contains("BrokenUserAgent") || userAgent.Contains("BrokenUserAgent2") } }
Konfigurieren Sie anschließend die OpenIdConnect-Einstellungen für die Verwendung des neuen CookieManager.
app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { // … Your preexisting options … CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()) });
Für SystemWebCookieManager muss der SameSite-Patch .NET 4.7.2 oder höher installiert sein, damit er ordnungsgemäß funktioniert.
Für ASP.NET Core sollten Sie die Patches installieren und dann den Agent-Sniffing-Code in einer
Cookie-Richtlinie implementieren. Für Versionen vor 3.1 ersetzen Sie SameSiteMode.Unspecified durch (SameSiteMode) (- 1).
private void CheckSameSite(HttpContext httpContext, CookieOptions options) { if (options.SameSite > SameSiteMode.Unspecified) { var userAgent = httpContext.Request.Headers["User-Agent"].ToString(); // TODO: Use your User Agent library of choice here. if (/* UserAgent doesn't support new behavior */) { // For .NET Core < 3.1 set SameSite = -1 options.SameSite = SameSiteMode.Unspecified; } } } public void ConfigureServices(IServiceCollection services) { services.Configure<CookiePolicyOptions>(options => { options.MinimumSameSitePolicy = SameSiteMode.Unspecified; options.OnAppendCookie = cookieContext => CheckSameSite(cookieContext.Context, cookieContext.CookieOptions); options.OnDeleteCookie = cookieContext => CheckSameSite(cookieContext.Context, cookieContext.CookieOptions); }); } public void Configure(IApplicationBuilder app) { app.UseCookiePolicy(); // Before UseAuthentication or anything else that writes cookies. app.UseAuthentication(); // … }
Beim Testen mit dem Azure Active Directory-Team haben wir festgestellt, dass die folgenden Überprüfungen für alle allgemeinen Benutzeragenten funktionieren, die Azure Active Directory sieht und die den neuen Wert nicht verstehen.
public 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 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. if (userAgent.Contains("Macintosh; Intel Mac OS X 10_14") && userAgent.Contains("Version/") && userAgent.Contains("Safari")) { 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. if (userAgent.Contains("Chrome/5") || userAgent.Contains("Chrome/6")) { return true; } return false; }
Diese Browserliste ist keineswegs kanonisch und Sie sollten überprüfen, ob sich die von Ihrem System unterstützten allgemeinen Browser und anderen Benutzeragenten nach dem Update wie erwartet verhalten.
Chrome 80 soll
das neue Verhalten im Februar oder März 2020 aktivieren, einschließlich einer vorübergehenden Reduzierung, die in Chrome 79 Beta hinzugefügt wurde. Wenn Sie das neue Verhalten ohne Schadensbegrenzung testen möchten, verwenden Sie Chromium 76. Ältere Versionen von Chromium
stehen zum Download zur Verfügung .
Wenn Sie Ihre Framework-Versionen nicht aktualisieren können, bis Chrome das neue Verhalten Anfang 2020 ändert, können Sie Ihren OpenIdConnect-Flow möglicherweise in einen Code-Flow ändern, anstatt in den impliziten Standard-Flow, den ASP.NET und ASP.NET Core verwenden Dies sollte als vorübergehende Maßnahme angesehen werden.
Wir empfehlen Ihnen dringend, die aktualisierten Versionen von .NET Framework und .NET Core herunterzuladen, sobald sie im November verfügbar sind, und mit der Planung Ihres Updates zu beginnen, bevor die Änderungen von Chrome eingeführt werden.