Schematische SameSite

Die Definition von „same-site“ umfasst nun auch das URL-Schema, sodass Links zwischen HTTP- und HTTPS-Versionen einer Website jetzt als websiteübergreifende Anfragen gezählt werden. Führen Sie standardmäßig ein Upgrade auf HTTPS durch, um Probleme zu vermeiden, oder lesen Sie weiter, um zu erfahren, welche SameSite-Attributwerte erforderlich sind.

Steven Bingler

Rowan Merewood

Schemeful Same-Site ändert die Definition einer (Website) von der registrierbaren Domain in die Schema- und registrierbare Domain. Weitere Details und Beispiele finden Sie unter Informationen zu „same-site“ und „same-origin“.

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

Falls Sie Ihre Website noch nicht vollständig umgestellt haben, sollte dies die höchste Priorität haben. Falls Besucher Ihrer Website jedoch zwischen HTTP und HTTPS wechseln, finden Sie nachfolgend einige dieser häufigen Szenarien und das damit verbundene Verhalten des SameSite-Cookies.

Du kannst diese Änderungen sowohl für Tests in Chrome als auch in Firefox aktivieren.

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

Einer der Hauptgründe für die Änderung von SameSite=Lax als Standardwert für Cookies war der Schutz vor Cross-Site Request Forgery (CSRF). Unsicherer HTTP-Traffic bietet jedoch Netzwerkangreifern dennoch die Möglichkeit, Cookies zu manipulieren, die dann auf der sicheren HTTPS-Version der Website verwendet werden. Durch die Erstellung dieser zusätzlichen websiteübergreifenden Grenze zwischen Schemas sind Sie noch besser vor diesen Angriffen geschützt.

Häufige Szenarien für mehrere Schemata

Navigation

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

Unterressourcen werden geladen

Alle Änderungen, die Sie hier vornehmen, gelten nur als vorübergehende Korrektur, während Sie das Upgrade auf die vollständige HTTPS-Version durchführen.

Beispiele für Unterressourcen sind Bilder, iFrames und Netzwerkanfragen mit XHR oder Fetch.

Durch das Laden einer schemaübergreifenden Unterressource auf einer Seite konnten bisher SameSite=Strict- oder SameSite=Lax-Cookies gesendet oder festgelegt werden. Jetzt wird dies wie alle anderen Drittanbieter- oder websiteübergreifenden Unterressourcen behandelt. Das bedeutet, dass alle SameSite=Strict- oder SameSite=Lax-Cookies blockiert werden.

Selbst wenn der Browser das Laden von Ressourcen unsicherer Schemas auf einer sicheren Seite zulässt, werden alle Cookies bei diesen Anfragen blockiert, da für Drittanbieter- oder websiteübergreifende Cookies Secure erforderlich ist.

Formulare posten

Beim Posten zwischen schemaübergreifenden Versionen einer Website konnten bisher mit SameSite=Lax oder SameSite=Strict festgelegte Cookies gesendet werden. Jetzt wird dies als websiteübergreifende POST-Anfrage behandelt – es können nur SameSite=None-Cookies gesendet werden. Dieses Szenario kann auf Websites auftreten, auf denen standardmäßig die unsichere Version verwendet wird. Nutzer werden jedoch beim Senden des Anmelde- oder Check-out-Formulars auf die sichere Version aktualisiert.

Wie bei Unterressourcen werden alle Cookies bei diesen Anfragen blockiert, wenn die Anfrage von einem sicheren Kontext (z.B. HTTPS) an einen unsicheren Kontext (z.B. HTTP) weitergeleitet wird, da für Drittanbieter- oder websiteübergreifende Cookies Secure erforderlich ist.

Wie kann ich meine Website testen?

Tools und Mitteilungen für Entwickler sind in Chrome und Firefox verfügbar.

Ab Chrome 86 enthält der Tab „Problem“ in den Entwicklertools Informationen zu Schemeful Same-Site-Problemen. Für Ihre Website werden möglicherweise die folgenden Probleme hervorgehoben.

Probleme mit der Navigation:

• „Migrieren Sie vollständig zu HTTPS, damit weiterhin Cookies bei Anfragen derselben Website gesendet werden“: Es wird eine Warnung angezeigt, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
• „Migration vollständig zu HTTPS, damit Cookies bei Anfragen von derselben Website gesendet werden“: Eine Warnung, dass das Cookie blockiert wurde.

Probleme beim Laden von Unterressourcen:

• „Migrieren Sie vollständig zu HTTPS, damit Cookies weiterhin an Unterressourcen derselben Website gesendet werden“ oder „Migrieren Sie vollständig zu HTTPS, um weiterhin Cookies durch Unterressourcen derselben Website zu setzen“: Warnungen, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
• „Migration vollständig zu HTTPS, damit Cookies an Unterressourcen derselben Website gesendet werden“ oder „Migrieren Sie vollständig zu HTTPS, damit Cookies von Unterressourcen derselben Website gesetzt werden können“ – Warnungen, dass das Cookie blockiert wurde. Die zweite Warnung kann auch beim Senden eines Formulars angezeigt werden.

Weitere Informationen finden Sie unter Test- und Debugging-Tipps für Schemeful Same-Site.

In Firefox 79 und network.cookie.sameSite.schemeful über about:config auf true gesetzt ist, zeigt die Konsole eine Meldung für Schemeful Same-Site-Probleme an. Auf Ihrer Website kann Folgendes angezeigt werden:

• „Das Cookie cookie_name wird bald als websiteübergreifendes Cookie für http://site.example/ behandelt, da das Schema nicht übereinstimmt.“
• „Das Cookie cookie_name wurde in Bezug auf http://site.example/ als websiteübergreifend behandelt, da das Schema nicht übereinstimmt.“

Häufig gestellte Fragen

Meine Website ist bereits vollständig über HTTPS verfügbar. Warum werden Probleme in den Entwicklertools meines Browsers angezeigt?

Es ist möglich, dass einige Ihrer Links und Unterressourcen immer noch auf unsichere URLs verweisen.

Eine Möglichkeit, dieses Problem zu beheben, besteht in der Verwendung von HTTP Strict-Transport-Security (HSTS) und der Anweisung includeSubDomain. Mit HSTS und includeSubDomain verwendet der Browser automatisch stattdessen die sichere Version, auch wenn eine Ihrer Seiten versehentlich einen unsicheren Link enthält.

Was passiert, wenn ich kein Upgrade auf HTTPS durchführen kann?

Zum Schutz Ihrer Nutzer empfehlen wir Ihnen dringend, Ihre Website vollständig auf HTTPS umzustellen. Falls Sie das nicht selbst tun können, sollten Sie sich an Ihren Hostanbieter wenden. Wenn Sie ein Zertifikat selbst hosten, bietet Let's Encrypt eine Reihe von Tools zum Installieren und Konfigurieren eines Zertifikats. Sie können Ihre Website auch hinter ein CDN oder einen anderen Proxy verlegen, der die HTTPS-Verbindung bereitstellen kann.

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

• 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 gesetzt werden, können Sie den Schutz auf None senken.
  • Diese Problemumgehung schlägt fehl, wenn die URL, an die Sie Cookies senden oder von der Sie Cookies setzen, nicht sicher ist. Das liegt daran, dass SameSite=None das Attribut Secure für Cookies erfordert. Diese Cookies werden also möglicherweise nicht über eine unsichere Verbindung gesendet oder gesetzt. In diesem Fall können Sie erst auf dieses Cookie zugreifen, wenn Ihre Website auf HTTPS aktualisiert wurde.
  • Denken Sie daran, dass dies nur vorübergehend ist, da Drittanbieter-Cookies schließlich ganz 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 hätten sie SameSite=Lax angegeben. Das gleiche Verhalten gilt auch für diese Cookies. Hinweis: Die vorübergehende Ausnahme von unsicheren Methoden gilt weiterhin. Weitere Informationen zur Abwehr von Lax- und POST-Anfragen in den SameSite-FAQs von Chromium

Foto von Julissa Capdevilla auf Unsplash