Schematische SameSite

Die Definition von „Same-Site“ wird weiterentwickelt und umfasst jetzt auch das URL-Schema. Links zwischen HTTP- und HTTPS-Versionen einer Website gelten jetzt als websiteübergreifende Anfragen. Wir empfehlen, standardmäßig auf HTTPS umzustellen, um Probleme zu vermeiden. Alternativ können Sie weiterlesen, um zu erfahren, welche Werte für das SameSite-Attribut erforderlich sind.

Steven Bingler

Rowan Merewood

Schemeful Same-Site ändert die Definition einer Website von der registrierbaren Domain in das Schema + die registrierbare Domain. Weitere Informationen und Beispiele finden Sie unter „Same-Site“ und „Same-Origin“.

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

Wenn Sie Ihre Website noch nicht vollständig umgestellt haben, sollten Sie das jetzt tun. Wenn Ihre Websitebesucher jedoch zwischen HTTP und HTTPS wechseln, werden einige dieser häufigen Szenarien und das zugehörige SameSite-Cookie-Verhalten später in diesem Artikel beschrieben.

Sie können diese Änderungen sowohl in Chrome als auch in Firefox für Tests aktivieren.

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

Einer der Hauptgründe für die Änderung von SameSite=Lax als Standard für Cookies war der Schutz vor websiteübergreifenden Anfragen (CSRF). Unsicherer HTTP-Traffic bietet Angreifern jedoch weiterhin die Möglichkeit, Cookies zu manipulieren, die dann in der sicheren HTTPS-Version der Website verwendet werden. Durch das Erstellen dieser zusätzlichen websiteübergreifenden Grenze zwischen Schemas wird der Schutz vor diesen Angriffen weiter verbessert.

Häufige schemaübergreifende Szenarien

Navigation

Bei der Navigation zwischen schemaübergreifenden Versionen einer Website (z. B. durch Verlinkung von http://site.example zu https://site.example) konnten bisher SameSite=Strict Cookies gesendet werden. Dies wird jetzt als websiteübergreifende Navigation behandelt, was bedeutet, dass SameSite=Strict-Cookies blockiert werden.

Unterressourcen laden

Alle Änderungen, die Sie hier vornehmen, sollten nur als vorübergehende Lösung betrachtet werden, während Sie auf vollständiges HTTPS umstellen.

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

Wenn eine schemaübergreifende Unterressource auf einer Seite geladen wurde, konnten bisher SameSite=Strict- oder SameSite=Lax-Cookies gesendet oder festgelegt werden. Jetzt wird dies genauso behandelt wie jede andere Drittanbieter- oder websiteübergreifende Unterressource. Das bedeutet, dass alle SameSite=Strict- oder SameSite=Lax-Cookies blockiert werden.

Auch wenn der Browser zulässt, dass Ressourcen aus unsicheren Schemas auf einer sicheren Seite geladen werden, werden alle Cookies für diese Anfragen blockiert, da für Drittanbieter- oder websiteübergreifende Cookies Secure erforderlich ist.

Formular per POST senden

Beim Senden von Daten zwischen schemaübergreifenden Versionen einer Website konnten bisher Cookies gesendet werden, die mit SameSite=Lax oder SameSite=Strict festgelegt wurden. Jetzt wird dies als websiteübergreifendes POST behandelt. Es können nur SameSite=None-Cookies gesendet werden. Dieses Szenario kann auf Websites auftreten, auf denen standardmäßig die unsichere Version angezeigt wird, Nutzer aber beim Senden des Anmelde- oder Kassenformulars auf die sichere Version umgestellt werden.

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

Wie kann ich meine Website testen?

In Chrome und Firefox sind Entwicklertools und entsprechende Meldungen verfügbar.

In Chrome 86 und höher werden auf dem Tab „Probleme“ in den Entwicklertools Probleme mit „Schemeful Same-Site“ angezeigt. Möglicherweise werden die folgenden Probleme für Ihre Website hervorgehoben.

Navigationsprobleme:

• „Migrieren Sie vollständig zu HTTPS, damit Cookies weiterhin bei Same-Site-Anfragen gesendet werden können“: Eine Warnung, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
• „Migrieren Sie vollständig zu HTTPS, damit Cookies bei Same-Site-Anfragen gesendet werden können“: Eine Warnung, dass das Cookie blockiert wurde.

Probleme beim Laden von Unterressourcen:

• „Migrieren Sie vollständig zu HTTPS, damit Cookies weiterhin an Same-Site-Unterressourcen gesendet werden können“ oder „Migrieren Sie vollständig zu HTTPS, damit Cookies weiterhin von Same-Site-Unterressourcen festgelegt werden können“: Warnungen, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
• „Migrieren Sie vollständig zu HTTPS, damit Cookies an Same-Site-Unterressourcen gesendet werden können“ oder „Migrieren Sie vollständig zu HTTPS, damit Cookies von Same-Site-Unterressourcen festgelegt werden können“: Warnungen, dass das Cookie blockiert wurde. Die zweite Warnung kann auch beim Senden eines Formulars per POST angezeigt werden.

Weitere Informationen finden Sie unter Tipps zum Testen und Debuggen für „Schemeful Same-Site“.

Wenn in Firefox 79 und höher network.cookie.sameSite.schemeful über about:config auf true festgelegt ist, werden in der Konsole Meldungen zu Problemen mit „Schemeful Same-Site“ angezeigt. Möglicherweise sehen Sie auf Ihrer Website Folgendes:

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

FAQ

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

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

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

Was ist, wenn ich nicht auf HTTPS umstellen kann?

Wir empfehlen dringend, Ihre Website vollständig auf HTTPS umzustellen, um Ihre Nutzer zu schützen. Wenn Sie das nicht selbst tun können, sollten Sie sich an Ihren Hostinganbieter wenden, um zu erfahren, ob er diese Option anbietet. Wenn Sie selbst hosten, dann Let's Encrypt bietet eine Reihe von Tools zum Installieren und Konfigurieren eines Zertifikats. Sie können auch in Erwägung ziehen, Ihre Website hinter ein CDN oder einen anderen Proxy zu verschieben, der die HTTPS-Verbindung bereitstellen kann.

Wenn das nicht möglich ist, können Sie den SameSite-Schutz für betroffene Cookies lockern.

• Wenn nur SameSite=Strict-Cookies blockiert werden, können Sie den Schutz auf Lax herabsetzen.
• Wenn sowohl Strict- als auch Lax-Cookies blockiert werden und Ihre Cookies an eine sichere URL gesendet oder von einer sicheren URL festgelegt werden, können Sie den Schutz auf None herabsetzen.
  • Diese Problemumgehung funktioniert nicht , wenn die URL, an die Sie Cookies senden (oder von der Sie sie festlegen), unsicher 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 können. In diesem Fall können Sie erst auf das Cookie zugreifen, wenn Ihre Website auf HTTPS umgestellt wurde.
  • Beachten Sie, dass dies nur eine vorübergehende Lösung 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 ein SameSite-Attribut werden so behandelt, als wäre SameSite=Lax angegeben. Das gleiche schemaübergreifende Verhalten gilt auch für diese Cookies . Beachten Sie, dass die vorübergehende Ausnahme für unsichere Methoden weiterhin gilt. Weitere Informationen finden Sie unter Lax + POST-Minderung in den Chromium SameSite FAQ .

Wie wirken sich die Änderungen auf WebSockets aus?

WebSocket-Verbindungen werden weiterhin als Same-Site betrachtet, wenn sie die gleiche Sicherheitsstufe wie die Seite haben.

Same-Site:

• wss://-Verbindung von https://
• ws://-Verbindung von http://

Websiteübergreifend:

• wss://-Verbindung von http://
• ws://-Verbindung von https://