Schematische SameSite

Die Definition von „auf derselben Website“ wird erweitert, um das URL-Schema einzubeziehen. Links zwischen HTTP- und HTTPS-Versionen einer Website gelten jetzt als websiteübergreifende Anfragen. Stellen Sie standardmäßig auf HTTPS um, um Probleme nach Möglichkeit zu vermeiden. Lesen Sie weiter, um zu erfahren, welche SameSite-Attributwerte erforderlich sind.

Steven Bingler

Rowan Merewood

Bei Schemaful wird die Definition einer (Web-)Website von nur der registrierbaren Domain in das Schema + registrierbare Domain geändert. Weitere Informationen und Beispiele finden Sie unter „Auf derselben Website“ und „Mit derselben Quelle“.

Die gute Nachricht: Wenn Ihre Website bereits vollständig auf HTTPS umgestellt ist, müssen Sie sich keine Sorgen machen. Für Sie ändert sich nichts.

Wenn Sie Ihre Website noch nicht vollständig umgestellt haben, sollten Sie dies als Priorität betrachten. Wenn Ihre Websitebesucher jedoch zwischen HTTP und HTTPS wechseln, werden einige dieser häufigen Szenarien und das zugehörige SameSite-Cookie-Verhalten weiter unten in diesem Artikel beschrieben.

Sie können diese Änderungen sowohl in Chrome als auch in Firefox aktivieren.

• Aktivieren Sie in Chrome 86 die Option about://flags/#schemeful-same-site. Den Fortschritt können Sie auf der Chrome-Statusseite verfolgen.
• Ab Firefox 79 können Sie network.cookie.sameSite.schemeful über about:config auf true festlegen. Sie können den Fortschritt über das Bugzilla-Problem verfolgen.

Einer der Hauptgründe für die Änderung zu SameSite=Lax als Standard für Cookies war der Schutz vor CSRF-Angriffen (Cross-Site Request Forgery). Unsicherer HTTP-Traffic bietet jedoch weiterhin die Möglichkeit für Netzwerkangreifer, mit Cookies zu manipulieren, die dann in der sicheren HTTPS-Version der Website verwendet werden. Durch das Erstellen dieser zusätzlichen websiteübergreifenden Grenze zwischen den Schemas wird ein weiterer Schutz vor diesen Angriffen geboten.

Gängige schemübergreifende Szenarien

Navigation

Beim Wechseln zwischen schemübergreifenden Versionen einer Website (z. B. beim Verknüpfen von http://beispiel.de zu https://beispiel.de) konnten bisher SameSite=Strict-Cookies gesendet werden. Dies wird jetzt als websiteübergreifende Navigation behandelt, was bedeutet, dass SameSite=Strict-Cookies blockiert werden.

Untergeordnete Ressourcen werden geladen

Alle hier vorgenommenen Änderungen sollten nur als vorübergehende Lösung betrachtet werden, während Sie auf die vollständige HTTPS-Umstellung hinarbeiten.

Beispiele für untergeordnete Ressourcen sind Bilder, Iframes und Netzwerkanfragen, die mit XHR oder Fetch gesendet werden.

Beim Laden einer schemübergreifenden Unterressource auf einer Seite konnten bisher SameSite=Strict- oder SameSite=Lax-Cookies gesendet oder festgelegt werden. Diese werden jetzt wie jede andere Drittanbieter- oder websiteübergreifende Unterressource behandelt. Das bedeutet, dass alle SameSite=Strict- oder SameSite=Lax-Cookies blockiert werden.

Selbst wenn der Browser das Laden von Ressourcen aus unsicheren Schemes auf einer sicheren Seite zulässt, werden alle Cookies bei diesen Anfragen blockiert, da Drittanbieter- oder websiteübergreifende Cookies Secure erfordern.

POST-Formular

Beim Posten zwischen schemübergreifenden Versionen einer Website konnten bisher Cookies gesendet werden, die mit SameSite=Lax oder SameSite=Strict festgelegt wurden. Diese Anfrage wird jetzt als websiteübergreifende POST-Anfrage behandelt. Es können nur SameSite=None-Cookies gesendet werden. Dieses Szenario kann auf Websites auftreten, die standardmäßig die unsichere Version anzeigen, Nutzer aber beim Senden des Anmelde- oder Zahlungsformulars auf die sichere Version umstellen.

Wie bei untergeordneten Ressourcen werden bei einer Anfrage von einem sicheren Kontext (z. B. HTTPS) an einen unsicheren Kontext (z. B. HTTP) alle Cookies für diese Anfragen blockiert, da Drittanbieter- oder websiteübergreifende Cookies Secure erfordern.

Wie kann ich meine Website testen?

Entwicklertools und -mitteilungen sind in Chrome und Firefox verfügbar.

Ab Chrome 86 werden auf dem Tab „Probleme“ in den Entwicklertools Probleme mit schemful SameSite-Cookies aufgeführt. Möglicherweise werden für Ihre Website die folgenden Probleme hervorgehoben.

Navigationsprobleme:

• „Komplett zu HTTPS migrieren, damit weiterhin Cookies bei Anfragen auf derselben Website gesendet werden“: Eine Warnung, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
• „Komplett zu HTTPS migrieren, damit Cookies bei Anfragen auf derselben Website gesendet werden“: Eine Warnung, dass das Cookie blockiert wurde.

Probleme beim Laden von untergeordneten Ressourcen:

• „Komplett zu HTTPS migrieren, damit weiterhin Cookies an Unterressourcen auf derselben Website gesendet werden“ oder „Komplett zu HTTPS migrieren, damit weiterhin Cookies von Unterressourcen auf derselben Website gesetzt werden können“: Warnungen, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
• „Vollständig zu HTTPS migrieren, damit Cookies an untergeordnete Ressourcen auf derselben Website gesendet werden“ oder „Vollständig zu HTTPS migrieren, damit Cookies von untergeordneten Ressourcen auf derselben Website gesetzt werden können“: Warnungen, dass das Cookie blockiert wurde. Letztere Warnung kann auch beim POSTen eines Formulars angezeigt werden.

Weitere Informationen finden Sie unter Tipps zum Testen und Entfernen von Fehlern für Schemeful Same-Site.

Ab Firefox 79 wird in der Console eine Meldung zu Problemen mit richtlinienkonformen Same-Site-Anforderungen angezeigt, wenn network.cookie.sameSite.schemeful über about:config auf true festgelegt ist. Auf Ihrer Website wird möglicherweise Folgendes angezeigt:

• „Das Cookie cookie_name wird bald als websiteübergreifendes Cookie im Vergleich zu http://site.example/ behandelt, da das Schema nicht übereinstimmt.“
• „Das Cookie cookie_name wurde als websiteübergreifend im Vergleich zu http://site.example/ behandelt, da das Schema nicht übereinstimmt.“

FAQ

Meine Website ist bereits vollständig über HTTPS verfügbar. Warum sehe ich Probleme in den DevTools meines Browsers?

Möglicherweise verweisen einige Ihrer Links und untergeordneten Ressourcen noch auf unsichere URLs.

Eine Möglichkeit zur Behebung dieses Problems ist die Verwendung von HTTP Strict Transport Security (HSTS) und der includeSubDomain-Richtlinie. Mit HSTS + includeSubDomain verwendet der Browser auch dann automatisch die sichere Version, wenn eine Ihrer Seiten versehentlich einen unsicheren Link enthält.

Was passiert, wenn ich nicht auf HTTPS umstellen kann?

Wir empfehlen Ihnen dringend, Ihre Website vollständig auf HTTPS umzustellen, um Ihre Nutzer zu schützen. Wenn Sie das nicht selbst tun können, wenden Sie sich an Ihren Hostinganbieter, um zu erfahren, ob er diese Option anbietet. Wenn Sie selbst hosten, bietet Let's Encrypt eine Reihe von Tools zur Installation und Konfiguration eines Zertifikats. Sie können auch prüfen, ob Sie Ihre Website hinter ein CDN oder einen anderen Proxy stellen, der die HTTPS-Verbindung bereitstellen kann.

Wenn das immer noch nicht möglich ist, lockern Sie den SameSite-Schutz für die betroffenen Cookies.

• Wenn nur SameSite=Strict-Cookies blockiert werden, können Sie den Schutz auf Lax senken.
• Wenn sowohl Strict- als auch Lax-Cookies blockiert werden und Ihre Cookies an eine sichere URL gesendet oder von einer sicheren URL aus festgelegt werden, können Sie den Schutz auf None senken.
  • Diese Behelfslösung funktioniert nicht, wenn die URL, an die Sie Cookies senden oder von der aus Sie sie festlegen, nicht sicher ist. Das liegt daran, dass für SameSite=None das Attribut Secure für Cookies erforderlich ist. Das bedeutet, dass diese Cookies nicht über eine unsichere Verbindung gesendet oder festgelegt werden dürfen. In diesem Fall können Sie erst auf das Cookie zugreifen, wenn Ihre Website auf HTTPS umgestellt wurde.
  • Denken Sie daran, dass dies nur vorübergehend ist, da Drittanbieter-Cookies letztendlich vollständig eingestellt werden.

Wie wirkt sich das auf meine Cookies aus, wenn ich kein SameSite-Attribut angegeben habe?

Cookies ohne SameSite-Attribut werden so behandelt, als wäre SameSite=Lax angegeben. Für diese Cookies gilt dasselbe schemübergreifende Verhalten. Die vorübergehende Ausnahme für unsichere Methoden gilt weiterhin. Weitere Informationen finden Sie in den SameSitehäufig gestellten Fragen zu Chromium unter Lax- und POST-Mitigation.

Foto von Julissa Capdevilla auf Unsplash