Schematische SameSite

Die Definition von „same-site“ wird das URL-Schema erweitert, sodass Verknüpfungen zwischen HTTP- und HTTPS-Versionen einer Website jetzt als websiteübergreifende Anfragen gezählt werden. Führen Sie 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

Hinweis: Dieser Artikel ist Teil einer Reihe über die Änderungen bei den SameSite-Cookie-Attributen, die Folgendes umfassen:

• Cookies
• SameSite-Cookies
• Rezepte für SameSite-Cookies

Schemata SameSite ändert die Definition einer (Website)-Website, von der registrierfähigen Domain Schema + registrierfähige Domain. Weitere Details und Beispiele finden Sie in Funktionsweise von „same-site“ und „same-origin“ aus.

Schlüsselbegriff : Die unsichere HTTP-Version einer Website, z. B. http://website.beispiel, und die sichere HTTPS-Version dieser Website, https://website.beispiel, werden jetzt als websiteübergreifend zueinander betrachtet.

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

Falls Sie Ihre Website noch nicht vollständig umgestellt haben, sollte diese Umstellung Priorität haben. Falls es jedoch Fälle gibt, in denen die Besucher Ihrer Website zwischen HTTP und HTTPS dann einige dieser üblichen Szenarien und das zugehörige SameSite-Cookie werden im Folgenden beschrieben.

Warnung : Langfristig wird die Unterstützung von Drittanbieter-Cookies vollständig eingestellt und durch datenschutzfreundliche Alternativen ersetzt. Das Festlegen von SameSite=None; Secure für ein Cookie, damit es über Schemas gesendet werden kann, sollte bei der Migration zu vollständigem HTTPS nur als temporäre Lösung betrachtet werden.

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

• Ab Chrome 86: about://flags/#schemeful-same-site aktivieren. Fortschritt im Blick behalten über den Chrome-Status .
• Setze in Firefox 79 network.cookie.sameSite.schemeful auf true über about:config Verfolge den Fortschritt über Bugzilla .

Einer der Hauptgründe für die Änderung von SameSite=Lax als Standard für Cookies diente zum Schutz vor Cross-Site Request Forgery (CSRF) fest. Sie können jedoch unsicherer HTTP-Traffic bietet Netzwerkangreifern aber trotzdem die Möglichkeit, Manipulation von Cookies, die dann in der sicheren HTTPS-Version der Website. Das Erstellen dieser zusätzlichen websiteübergreifenden Begrenzung zwischen Schemas bietet weitere Abwehrmaßnahmen gegen diese Angriffe.

Häufige Szenarien bei verschiedenen Schemas

Wichtiger Begriff : In den Beispielen unten haben alle URLs dieselbe registrierfähige Domain, z.B. „site.beispiel“, aber unterschiedliche Schemas, z. B. http://site.beispiel und https://site.beispiel, werden als Cross-Schema zueinander bezeichnet.

Navigation

Navigieren zwischen schemaübergreifenden Versionen einer Website (z. B. Verlinkung von http://website.beispiel zu https://website.beispiel). SameSite=Strict Cookies werden gesendet. Dies wird jetzt als websiteübergreifende Das bedeutet, dass SameSite=Strict-Cookies blockiert werden.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Schemaübergreifende Navigation von HTTP zu HTTPS

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blockiert	⛔ Blockiert
SameSite=Lax	✓ Zulässig	✓ Zulässig
SameSite=None;Secure	✓ Zulässig	⛔ Blockiert

Untergeordnete Ressourcen werden geladen

Warnung : Alle gängigen Browser blockieren aktive gemischte Inhalte wie Skripts oder iFrames. Darüber hinaus arbeiten Browser wie Chrome und Firefox daran, passive gemischte Inhalte zu aktualisieren oder zu blockieren.

Änderungen, die Sie hier vornehmen, sollten nur als vorübergehende Korrektur betrachtet werden, wenn Sie die Umstellung auf vollständiges HTTPS.

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

Wenn eine schemaübergreifende Unterressource auf einer Seite geladen werden konnte, SameSite=Strict- oder SameSite=Lax-Cookies, die gesendet oder gesetzt werden sollen. Das ist jetzt wie jede andere Drittanbieter- oder websiteübergreifende Unterressource behandelt, bedeutet, dass alle SameSite=Strict- oder SameSite=Lax-Cookies blockiert werden.

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Eine HTTP-Seite mit einer Cross-Schema-Unterressource über HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blockiert	⛔ Blockiert
SameSite=Lax	⛔ Blockiert	⛔ Blockiert
SameSite=None;Secure	✓ Zulässig	⛔ Blockiert

Formulare veröffentlichen

Früher ermöglichten Veröffentlichungen zwischen schemaübergreifenden Versionen einer Website Mit SameSite=Lax oder SameSite=Strict festgelegte Cookies, die gesendet werden sollen. Das ist jetzt als websiteübergreifende POST-Anfrage behandelt – nur SameSite=None Cookies können gesendet werden. Sie können auf Websites, die standardmäßig die unsichere Version verwenden, aber aktualisieren Sie die Nutzer beim Senden der Anmeldung oder aus.

Wenn die Anfrage wie bei Unterressourcen von einer sicheren Quelle stammt, z.B. HTTPS, an eine unsicher, z.B. HTTP, Kontext, dann werden alle Cookies für diese Anfragen blockiert. da Drittanbieter- oder websiteübergreifende Cookies Secure benötigen.

Warnung : Die beste Lösung ist, dafür zu sorgen, dass sowohl die Formularseite als auch das Ziel über eine sichere Verbindung wie HTTPS verbunden sind. Dies ist besonders wichtig, wenn der Nutzer vertrauliche Informationen in das Formular eingibt.

Schemaübergreifende Formularübermittlung von HTTP zu HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blockiert	⛔ Blockiert
SameSite=Lax	⛔ Blockiert	⛔ Blockiert
SameSite=None;Secure	✓ Zulässig	⛔ Blockiert

Wie kann ich meine Website testen?

Entwicklertools und Messaging sind in Chrome und Firefox verfügbar.

In Chrome 86 ist der Tab „Probleme“ in Entwicklertools Probleme mit Schemeful-Same-Site-Anzeigen enthalten. Möglicherweise werden die folgenden Probleme hervorgehoben für Ihre Website.

Probleme bei der Navigation:

• Vollständig zu HTTPS migrieren, damit Cookies weiterhin an dieselbe Website gesendet werden „requests“ (Anfragen): Eine Warnung, dass das Cookie in einer zukünftigen Version blockiert wird. von Chrome.
• Vollständig zu HTTPS migrieren, damit Cookies bei Anfragen auf derselben Website gesendet werden: Warnung, dass das Cookie blockiert wurde.

Probleme beim Laden von Unterressourcen:

• Vollständig zu HTTPS migrieren, damit Cookies weiterhin an dieselbe Website gesendet werden untergeordnete Ressourcen“ oder „Vollständig zu HTTPS migrieren, damit Cookies weiterhin wird von untergeordneten Ressourcen der gleichen Website festgelegt: Es wird eine Warnung angezeigt, dass das Cookie ein in einer zukünftigen Version von Chrome blockiert.
• „Vollständig zu HTTPS migrieren, damit Cookies an Unterressourcen derselben Website gesendet werden“ oder „Vollständig zu HTTPS migrieren, damit Cookies von derselben Website gesetzt werden können subresources": Es wird eine Warnung angezeigt, dass das Cookie blockiert wurde. Letzteres Eine Warnung kann auch beim POSTEN eines Formulars angezeigt werden.

Weitere Informationen finden Sie unter Tipps zum Testen und Debugging für Schemaful SameSite sein.

Aus Firefox 79 mit network.cookie.sameSite.schemeful auf true eingestellt über about:config wird in der Console eine Meldung für Probleme mit Schemeful SameSite angezeigt. Folgendes kann auf Ihrer Website angezeigt werden:

• „Das Cookie cookie_name wird demnächst als websiteübergreifendes Cookie behandelt http://site.example/, weil das Schema nicht übereinstimmt.“
• „Das Cookie cookie_name wurde als websiteübergreifend behandelt http://site.example/, weil das Schema nicht übereinstimmt.“

FAQ

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 Ressourcen verweisen. URLs.

Eine Möglichkeit, dieses Problem zu beheben, ist die Verwendung von HTTP Strikte Transportsicherheit (HSTS) und der includeSubDomain-Anweisung. Mit HSTS und includeSubDomain sogar Wenn eine Ihrer Seiten versehentlich einen unsicheren Link enthält, wird der Browser automatisch die sichere Version verwenden.

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

Auch wenn wir Ihnen dringend empfehlen, Ihre Website vollständig auf HTTPS zu aktualisieren, schützen Sie Ihre Nutzer. Falls Sie dies nicht selbst tun können, schlagen Sie vor, Ihren Hostanbieter fragen, ob er Ihnen diese Option anbieten kann. Wenn Sie Selbstveranstalter sind, bietet Let's Encrypt verschiedene Tools, ein Zertifikat installieren und konfigurieren. Sie können auch die Verschiebung Ihrer Website hinter einem CDN oder einem anderen Proxy, der die HTTPS-Verbindung herstellen kann.

Sollte dies immer noch nicht möglich sein, versuche, den SameSite-Schutz zu lockern betroffene Cookies.

• Wenn nur SameSite=Strict Cookies blockiert werden, können Sie die die Schutzmaßnahme auf Lax.
• Falls sowohl das Strict- als auch das Lax-Cookie blockiert wird und Ihr Cookies an eine sichere URL gesendet oder von dieser gesetzt werden. Sie können den Schutzmaßnahmen auf None umzustellen.
  • Diese Behelfslösung schlägt fehl, wenn die URL, an die Sie Cookies senden (oder festlegen) ist unsicher. Das liegt daran, dass SameSite=None das Secure-Attribut für Cookies, was bedeutet, dass diese Cookies möglicherweise nicht über eine unsichere Verbindung festgelegt. In diesem Fall können Sie nicht mehr auf bis Ihre Website auf HTTPS umgestellt wird.
  • Denken Sie daran, dass dies nur vorübergehend ist, da Drittanbieter-Cookies letztendlich ganz auslaufen lassen.

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

Cookies ohne SameSite-Attribut werden so behandelt, als wären sie angegeben SameSite=Lax und es gilt das gleiche schemaübergreifende Verhalten wie für diese Cookies: gut. Beachten Sie, dass die vorübergehende Ausnahme für unsichere Methoden weiterhin gilt, siehe Abwehr von Lax + POST in Chromium SameSite FAQs.

Wie sind WebSockets betroffen?

WebSocket-Verbindungen werden als dieselbe Website betrachtet, wenn sie identisch sind die Sicherheit der Seite.

Gleiche Website:

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

Websiteübergreifend:

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

Foto von Julissa Capdevilla am Unsplash