Freigeben über

Arbeiten mit SameSite-Cookies in ASP.NET

Von Rick Anderson

SameSite ist ein IETF-Entwurfsstandard, der einen gewissen Schutz vor Angriffen durch siteübergreifende Anforderungsfälschung (Cross-Site Request Forgery, CSRF) bieten soll. Ursprünglich wurde der Entwurfsstandard in 2016 entworfen und in 2019 aktualisiert. Der aktualisierte Standard ist nicht abwärtskompatibel mit dem vorherigen Standard, wobei die folgenden Unterschiede am deutlichsten sind:

  • Cookies ohne SameSite-Header werden standardmäßig wie SameSite=Lax folgt behandelt.
  • SameSite=None muss verwendet werden, um die Verwendung siteübergreifender Cookies zuzulassen.
  • Cookies, die behaupten SameSite=None , müssen auch als Securegekennzeichnet werden.
  • Anwendungen, die verwenden <iframe> , können Probleme mit sameSite=Lax oder sameSite=Strict Cookies haben, da <iframe> sie als websiteübergreifende Szenarien behandelt werden.
  • Der Wert SameSite=None ist nach dem Standard 2016 nicht zulässig und bewirkt, dass einige Implementierungen cookies wie SameSite=Strictbehandeln. Weitere Informationen finden Sie unter Unterstützung älterer Browser in diesem Dokument.

Die SameSite=Lax Einstellung funktioniert für die meisten Anwendungscookies. Einige Formen der Authentifizierung wie OpenID Connect (OIDC) und Webdiensteverbund verwenden standardmäßig POST-basierte Umleitungen. Die POST-basierten Umleitungen lösen die SameSite-Browserschutzmaßnahmen aus, sodass SameSite für diese Komponenten deaktiviert ist. Die meisten OAuth-Anmeldungen sind davon nicht betroffen, da die Anforderungen unterschiedlich verlaufen.

Jede ASP.NET Komponente, die Cookies ausgibt, muss entscheiden, ob SameSite geeignet ist.

Informationen zu Problemen mit Anwendungen nach der Installation der .Net SameSite-Updates 2019 finden Sie unter Bekannte Probleme .

Verwenden von SameSite in ASP.NET 4.7.2 und 4.8

.Net 4.7.2 und 4.8 unterstützen den Standardentwurf 2019 für SameSite seit der Veröffentlichung von Updates im Dezember 2019. Entwickler können den Wert des SameSite-Headers mithilfe der HttpCookie.SameSite-Eigenschaft programmgesteuert steuern. Das Festlegen der SameSite Eigenschaft auf Strict, Laxoder None führt dazu, dass diese Werte mit dem Cookie in das Netzwerk geschrieben werden. Wenn sie gleich ist, (SameSiteMode)(-1) wird angegeben, dass kein SameSite-Header im Netzwerk mit dem Cookie enthalten sein sollte. Die HttpCookie.Secure-Eigenschaft oder "requireSSL" in Konfigurationsdateien kann verwendet werden, um das Cookie als Secure oder nicht zu kennzeichnen.

Neue HttpCookie Instanzen werden standardmäßig auf und Secure=falsefestgelegtSameSite=(SameSiteMode)(-1). Diese Standardwerte können im system.web/httpCookies Konfigurationsabschnitt überschrieben werden, wobei die Zeichenfolge "Unspecified" eine benutzerfreundliche Konfigurationssyntax für (SameSiteMode)(-1)ist:

<configuration>
 <system.web>
  <httpCookies sameSite="[Strict|Lax|None|Unspecified]" requireSSL="[true|false]" />
 <system.web>
<configuration>

ASP.Net gibt auch vier eigene Cookies für diese Features aus: Anonyme Authentifizierung, Formularauthentifizierung, Sitzungsstatus und Rollenverwaltung. Instanzen dieser Cookies, die zur Laufzeit abgerufen werden, können mit den SameSite Eigenschaften und Secure wie alle anderen HttpCookie-instance bearbeitet werden. Aufgrund der Patchwork-Entwicklung des SameSite-Standards sind die Konfigurationsoptionen für diese vier Features jedoch inkonsistent. Die relevanten Konfigurationsabschnitte und Attribute mit Den Standardwerten sind unten dargestellt. Wenn für ein Feature kein SameSite oder Secure ein zugehöriges Attribut vorhanden ist, wird das Feature auf die im system.web/httpCookies obigen Abschnitt konfigurierten Standardwerte zurückgesetzt.

<configuration>
 <system.web>
  <anonymousIdentification cookieRequireSSL="false" /> <!-- No config attribute for SameSite -->
  <authentication>
   <forms cookieSameSite="Lax" requireSSL="false" />
  </authentication>
  <sessionState cookieSameSite="Lax" /> <!-- No config attribute for Secure -->
  <roleManager cookieRequireSSL="false" /> <!-- No config attribute for SameSite -->
 <system.web>
<configuration>

Hinweis: "Nicht angegeben" ist derzeit nur für system.web/httpCookies@sameSite verfügbar. Wir hoffen, den zuvor gezeigten cookieSameSite-Attributen in zukünftigen Updates eine ähnliche Syntax hinzuzufügen. Das Festlegen (SameSiteMode)(-1) im Code funktioniert weiterhin für Instanzen dieser Cookies.*

Wenn Sie dies in einer anderen Sprache als Englisch lesen, teilen Sie uns dies in diesem GitHub-Diskussionsproblem mit, wenn Sie die Codekommentare in Ihrer Muttersprache sehen möchten.

Erneutes Abrufen von .NET-Apps

So zielen Sie auf .NET 4.7.2 oder höher ab:

  • Stellen Sie sicher , dassweb.config Folgendes enthält: 

    <system.web>
  <compilation targetFramework="4.7.2"/>
  <httpRuntime targetFramework="4.7.2"/>
</system.web>

  • Überprüfen Sie, ob die Projektdatei das richtige TargetFrameworkVersion enthält:

    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

    Weitere Informationen finden Sie im .NET-Migrationshandbuch .

  • Vergewissern Sie sich, dass NuGet-Pakete im Projekt auf die richtige Frameworkversion ausgerichtet sind. Sie können die richtige Frameworkversion überprüfen, indem Sie die packages.config-Datei untersuchen, z. B.:

    <?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.AspNet.Mvc" version="5.2.7" targetFramework="net472" />
  <package id="Microsoft.ApplicationInsights" version="2.4.0" targetFramework="net451" />
</packages>

    In der vorherigen dateipackages.config das Microsoft.ApplicationInsights Paket:

    • Richtet sich an .NET 4.5.1.
    • Sollte das targetFramework Attribut auf net472 aktualisiert haben, wenn ein aktualisiertes Paket für Ihr Frameworkziel vorhanden ist.

.NET-Versionen vor 4.7.2

Microsoft unterstützt keine .NET-Versionen niedriger als 4.7.2 zum Schreiben des Cookie-Attributs same-site. Wir haben keinen zuverlässigen Weg gefunden, um Folgendes zu erreichen:

  • Stellen Sie sicher, dass das Attribut basierend auf der Browserversion ordnungsgemäß geschrieben wird.
  • Abfangen und Anpassen von Authentifizierungs- und Sitzungscookies in älteren Frameworkversionen.

Behavior Changes durch den Dezember-Patch

Die spezifische Verhaltensänderung für .NET Framework ist die Interpretation des Werts durch die SameSiteNone Eigenschaft:

  • Vor dem Patch bedeutet ein Wert von None :
    • Geben Sie das Attribut überhaupt nicht aus.
  • Nach dem Patch:
    • Ein Wert von None bedeutet "Geben Sie das Attribut mit dem Wert " aus None.
    • Ein SameSite Wert von (SameSiteMode)(-1) bewirkt, dass das Attribut nicht ausgegeben wird.

Der SameSite-Standardwert für Formularauthentifizierungs- und Sitzungsstatuscookies wurde von None in Laxgeändert.

Zusammenfassung der Auswirkungen auf Änderungen auf Browser

Wenn Sie den Patch installieren und ein Cookie mit SameSite.Noneausgeben, geschieht eines von zwei Dingen:

  • Chrome v80 behandelt dieses Cookie gemäß der neuen Implementierung und erzwingt nicht dieselben Websiteeinschränkungen für das Cookie.
  • Alle Browser, die nicht zur Unterstützung der neuen Implementierung aktualisiert wurden, folgen der alten Implementierung. Die alte Implementierung besagt:
    • Wenn ein Wert angezeigt wird, den Sie nicht verstehen, ignorieren Sie ihn, und wechseln Sie zu den strengen Websiteeinschränkungen.

So bricht entweder die App in Chrome, oder Sie unterbrechen an zahlreichen anderen Stellen.

Verlauf und Änderungen

Die SameSite-Unterstützung wurde zuerst in .NET 4.7.2 mithilfe des Entwurfsstandards von 2016 implementiert.

Mit den Updates vom 19. November 2019 für Windows wurde .NET 4.7.2+ von der Norm 2016 auf den Standard 2019 aktualisiert. Für andere Versionen von Windows stehen weitere Updates zur Verfügung. Weitere Informationen finden Sie in KB-Artikeln, die SameSite in .NET Framework unterstützen.

Der Entwurf von 2019 der SameSite-Spezifikation:

  • Er ist nicht abwärtskompatibel mit dem Entwurf von 2016. Weitere Informationen finden Sie unter Unterstützung älterer Browser in diesem Dokument.
  • Gibt an, dass Cookies standardmäßig behandelt SameSite=Lax werden.
  • Gibt Cookies an, die explizit behaupten SameSite=None , um die websiteübergreifende Übermittlung zu ermöglichen, auch als Securegekennzeichnet werden sollen.
  • Wird von Patches unterstützt, die wie in den oben aufgeführten KB-Versionen beschrieben ausgegeben werden.
  • Wurde von Chrome standardmäßig im Februar 2020 aktiviert. Die Browser werden seit 2019 auf diesen Standard umgestellt.

Bekannte Probleme

Da die Spezifikationen für 2016 und 2019 nicht kompatibel sind, werden mit dem .NET Framework-Update vom November 2019 einige Änderungen eingeführt, die möglicherweise nicht kompatibel sind.

  • Sitzungsstatus- und Formularauthentifizierungscookies werden jetzt als Lax anstelle von nicht angegeben in das Netzwerk geschrieben.
    • Während die meisten Apps mit SameSite=Lax Cookies arbeiten, stellen Apps, die POST über Websites oder Anwendungen hinweg, die verwenden, iframe möglicherweise fest, dass ihre Sitzungsstatus- oder Formularautorisierungscookies nicht wie erwartet verwendet werden. Um dies zu beheben, ändern Sie den cookieSameSite Wert im entsprechenden Konfigurationsabschnitt, wie zuvor erläutert.
  • HttpCookies, die explizit im Code oder in der Konfiguration festgelegt SameSite=None wurden, verfügen jetzt über diesen Wert, der mit dem Cookie geschrieben wurde, während er zuvor nicht angegeben wurde. Dies kann Probleme mit älteren Browsern verursachen, die nur den Standardentwurf von 2016 unterstützen.
    • Wenn Sie Browser ansprechen, die den Standardentwurf 2019 mit SameSite=None Cookies unterstützen, denken Sie daran, diese Secure auch zu markieren, da sie möglicherweise nicht erkannt werden.
    • Verwenden Sie die App-Einstellungaspnet:SupressSameSiteNone=true, um das 2016-Verhalten des Nichtschreibens SameSite=Nonezu rückgängig machen. Beachten Sie, dass dies für alle HttpCookies in der App gilt.

Informationen dazu, wie Azure App Service das SameSite-Verhalten in .NET 4.7.2-Apps konfiguriert, finden Sie unter Azure App Service – SameSite-Cookiebehandlung und .NET Framework 4.7.2-Patch.

Unterstützung älterer Browser

Der SameSite-Standard von 2016 schreibt vor, dass unbekannte Werte als SameSite=Strict-Werte behandelt werden müssen. Apps, auf die von älteren Browsern aus zugegriffen wird, die den SameSite-Standard von 2016 unterstützen, können unterbrochen werden, wenn sie eine SameSite-Eigenschaft mit einem Wert von None erhalten. Web-Apps müssen eine Browsererkennung implementieren, wenn sie ältere Browser unterstützen wollen. ASP.NET implementiert keine Browsererkennung, da User-Agents Werte stark volatil sind und sich häufig ändern.

Der Ansatz von Microsoft zur Behebung des Problems besteht darin, Sie bei der Implementierung von Browsererkennungskomponenten zu unterstützen, um das sameSite=None Attribut aus Cookies zu entfernen, wenn bekannt ist, dass ein Browser es nicht unterstützt. Google rät, doppelte Cookies auszustellen, eines mit dem neuen Attribut und eines ohne das Attribut. Allerdings halten wir die Ratschläge von Google für begrenzt. Einige Browser, insbesondere mobile Browser, haben sehr kleine Grenzwerte für die Anzahl von Cookies, die eine Website oder einen Domänennamen senden kann. Das Senden mehrerer Cookies, insbesondere große Cookies wie Authentifizierungscookies, kann sehr schnell das Limit für mobile Browser erreichen, was zu App-Fehlern führt, die schwer zu diagnostizieren und zu beheben sind. Darüber hinaus gibt es als Framework ein großes Ökosystem aus Code und Komponenten von Drittanbietern, die möglicherweise nicht aktualisiert werden, um einen doppelten Cookie-Ansatz zu verwenden.

Der In den Beispielprojekten in diesem GitHub-Repository verwendete Browsererkennungscode ist in zwei Dateien enthalten.

Diese Erkennungen sind die gängigsten Browser-Agents, die den 2016-Standard unterstützen und für die das Attribut vollständig entfernt werden muss. Es ist nicht als vollständige Implementierung gedacht:

  • In Ihrer App werden möglicherweise Browser angezeigt, die von unseren Testwebsites nicht angezeigt werden.
  • Sie sollten bereit sein, Erkennungen nach Bedarf für Ihre Umgebung hinzuzufügen.

Wie Sie die Erkennung verknüpfen, hängt von der Version von .NET und dem verwendeten Webframework ab. Der folgende Code kann auf der HttpCookie-Aufrufwebsite aufgerufen werden:

private void CheckSameSite(HttpContext httpContext, HttpCookie cookie)
{
    if (cookie.SameSite == SameSiteMode.None)
    {
        var userAgent = httpContext.Request.UserAgent;
        if (BrowserDetection.DisallowsSameSiteNone(userAgent))
        {
            cookie.SameSite = (SameSiteMode)(-1);
        }
    }
}

Siehe die folgenden ASP.NET 4.7.2 SameSite-Cookiethemen:

Sicherstellen, dass Ihre Website zu HTTPS umgeleitet wird

Für ASP.NET 4.x, WebForms und MVC kann das URL-Rewrite-Feature von IIS verwendet werden, um alle Anforderungen an HTTPS umzuleiten. Der folgende XML-Code zeigt eine Beispielregel:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect to https" stopProcessing="true">
          <match url="(.*)"/>
          <conditions>
            <add input="{HTTPS}" pattern="Off"/>
            <add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

In lokalen Installationen von IIS URL Rewrite ist ein optionales Feature, das möglicherweise installiert werden muss.

Testen von Apps für SameSite-Probleme

Sie müssen Ihre App mit den von Ihnen unterstützten Browsern testen und Ihre Szenarien mit Cookies durchgehen. Cookieszenarien umfassen in der Regel

  • Anmeldeformulare
  • Externe Anmeldemechanismen wie Facebook, Azure AD, OAuth und OIDC
  • Seiten, die Anforderungen von anderen Websites annehmen
  • Seiten in Ihrer App, die in iframes eingebettet werden sollen

Sie sollten überprüfen, ob Cookies in Ihrer App erstellt, gespeichert und gelöscht werden.

Apps, die mit Remotestandorten interagieren, z. B. über die Anmeldung über Drittanbieter, müssen folgende Aktionen ausführen:

Testen Sie Web-Apps mithilfe einer Clientversion, die das neue SameSite-Verhalten abonnieren kann. Chrome, Firefox und Chromium Edge verfügen über neue Featureflags, die für Tests verwendet werden können. Nachdem Ihre App die SameSite-Patches angewendet hat, testen Sie sie mit älteren Clientversionen, insbesondere Safari. Weitere Informationen finden Sie unter Unterstützung älterer Browser in diesem Dokument.

Testen mit Chrome

Chrome 78+ liefert irreführende Ergebnisse, da es eine vorübergehende Risikominderung aufweist. Die temporäre Entschärfung von Chrome 78+ ermöglicht Cookies, die weniger als zwei Minuten alt sind. Chrome 76 oder 77 mit den entsprechenden aktivierten Testflags liefert genauere Ergebnisse. Um das neue SameSite-Verhalten zu testen, schalten Sie chrome://flags/#same-site-by-default-cookies auf Aktiviert um. Bei älteren Versionen von Chrome (75 und niedriger) wird gemeldet, dass mit der neuen None-Einstellung ein Fehler auftritt. Weitere Informationen finden Sie unter Unterstützung älterer Browser in diesem Dokument.

Google stellt keine älteren Chrome-Versionen zur Verfügung. Befolgen Sie die Anweisungen unter Herunterladen von Chromium, um ältere Versionen von Chrome zu testen. Laden Sie Chrome nicht über Links herunter, die bei der Suche nach älteren Versionen von Chrome bereitgestellt werden.

Ab der Canary-Version 80.0.3975.0 kann die temporäre Lax+POST-Entschärfung mithilfe des neuen --enable-features=SameSiteDefaultChecksMethodRigorously-Flags zu Testzwecken deaktiviert werden, um das Testen von Websites und Diensten im möglichen Endzustand des Features zu ermöglichen, in dem die Entschärfung entfernt wurde. Weitere Informationen finden Sie unter „The Chromium Projects“ SameSite Updates.

Testen mit Chrome 80 und höher

Laden Sie eine Version von Chrome herunter, die ihr neues Attribut unterstützt. Zum Zeitpunkt des Schreibens ist die aktuelle Version Chrome 80. Für Chrome 80 muss das Flag chrome://flags/#same-site-by-default-cookies aktiviert sein, um das neue Verhalten zu verwenden. Sie sollten auch (chrome://flags/#cookies-without-same-site-must-be-secure) aktivieren, um das bevorstehende Verhalten für Cookies zu testen, für die kein gleichesSite-Attribut aktiviert ist. Chrome 80 ist auf zielführend, um Cookies ohne das Attribut SameSite=Laxals zu behandeln, wenn auch mit einer zeitlich festgelegten Nachfrist für bestimmte Anforderungen. Um die zeitbestimmte Nachfrist zu deaktivieren, kann Chrome 80 mit dem folgenden Befehlszeilenargument gestartet werden:

--enable-features=SameSiteDefaultChecksMethodRigorously

Chrome 80 enthält Warnmeldungen in der Browserkonsole über fehlende gleicheSite-Attribute. Verwenden Sie F12, um die Browserkonsole zu öffnen.

Testen mit Safari

Safari 12 hat den vorherigen Entwurf strikt implementiert und schlägt fehl, wenn sich der neue None Wert in einem Cookie befindet. None wird über den Browsererkennungscode vermieden: Unterstützung älterer Browser in diesem Dokument. Testen Sie Anmeldungen im Stil von Safari 12, Safari 13 und WebKit-basierten Betriebssystemen mithilfe von MSAL, ADAL oder der von Ihnen verwendeten Bibliothek. Das Problem hängt von der zugrunde liegenden Betriebssystemversion ab. Bei OSX Mojave (10.14) und iOS 12 sind Kompatibilitätsprobleme mit dem neuen SameSite-Verhalten bekannt. Das Problem lässt sich mit einem Upgrade des Betriebssystems auf OSX Catalina (10.15) bzw. iOS 13 beheben. Safari verfügt derzeit nicht über ein Aktivierungsflag zum Testen des neuen Spezifikationsverhaltens.

Testen mit Firefox

Die Firefox-Unterstützung für den neuen Standard kann in Version 68+ getestet werden, indem Sie sich auf der Seite about:config mit dem Featureflag network.cookie.sameSite.laxByDefault anmelden. Es liegen keine Berichte über Kompatibilitätsprobleme mit älteren Versionen von Firefox vor.

Testen mit Dem Edge-Browser (Legacy)

Edge unterstützt den alten SameSite-Standard. Edge version 44+ weist keine bekannten Kompatibilitätsprobleme mit dem neuen Standard auf.

Testen mit Edge (Chromium)

SameSite-Flags werden auf der Seite edge://flags/#same-site-by-default-cookies festgelegt. Es wurden keine Kompatibilitätsprobleme mit Edge Chromium festgestellt.

Testen mit Elektronen

Zu den Electron-Versionen zählen ältere Versionen von Chromium. Die von Teams verwendete Version von Electron ist beispielsweise Chromium 66, was das ältere Verhalten aufweist. Sie müssen Eigene Kompatibilitätstests mit der Von Ihrem Produkt verwendeten Electron-Version durchführen. Weitere Informationen finden Sie unter Unterstützen älterer Browser.

Zurücksetzen von SameSite-Patches

Sie können das aktualisierte Websiteverhalten in .NET Framework Apps auf das vorherige Verhalten rückgängig machen, bei dem das attribut sameSite für einen Wert von Nonenicht ausgegeben wird, und rückgängig machen die Authentifizierungs- und Sitzungscookies den Wert nicht ausgeben. Dies sollte als eine äußerst temporäre Korrektur angesehen werden, da die Chrome-Änderungen alle externen POST-Anforderungen oder die Authentifizierung für Benutzer mit Browsern unterbrechen, die die Änderungen am Standard unterstützen.

Wiederherstellen des .NET 4.7.2-Verhaltens

Aktualisieren Sieweb.config , um die folgenden Konfigurationseinstellungen einzuschließen:

<configuration> 
  <appSettings>
    <add key="aspnet:SuppressSameSiteNone" value="true" />
  </appSettings>
 
  <system.web> 
    <authentication> 
      <forms cookieSameSite="None" /> 
    </authentication> 
    <sessionState cookieSameSite="None" /> 
  </system.web> 
</configuration>

Zusätzliche Ressourcen

  • Last updated on