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.
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.
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.
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
auftrue
überabout: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
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.
![Schemaübergreifende Navigation, die ausgelöst wird, wenn ein Link in der unsicheren HTTP-Version einer Website zur sicheren HTTPS-Version folgt. SameSite=Strict-Cookies blockiert, SameSite=Lax und SameSite=None; Sichere Cookies sind zulässig.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=6&hl=de)
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Blockiert | ⛔ Blockiert |
SameSite=Lax
|
✓ Zulässig | ✓ Zulässig |
SameSite=None;Secure
|
✓ Zulässig | ⛔ Blockiert |
Untergeordnete Ressourcen werden geladen
Ä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
.
![Eine schemaübergreifende Unterressource, die aus einer Ressource aus der sicheren HTTPS-Version der Website resultiert, die in der unsicheren HTTP-Version enthalten ist. SameSite=Strict- und SameSite=Lax-Cookies blockiert und SameSite=None; Sichere Cookies sind zulässig.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=6&hl=de)
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.
![Schemaübergreifende Formulareinreichung, die aus einem Formular in der unsicheren HTTP-Version der Website resultiert, die an die sichere HTTPS-Version gesendet wird. SameSite=Strict- und SameSite=Lax-Cookies blockiert und SameSite=None; Sichere Cookies sind zulässig.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=6&hl=de)
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 behandelthttp://site.example/
, weil das Schema nicht übereinstimmt.“ - „Das Cookie
cookie_name
wurde als websiteübergreifend behandelthttp://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 aufLax
. - Falls sowohl das
Strict
- als auch dasLax
-Cookie blockiert wird und Ihr Cookies an eine sichere URL gesendet oder von dieser gesetzt werden. Sie können den Schutzmaßnahmen aufNone
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
dasSecure
-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.
- Diese Behelfslösung schlägt fehl, wenn die URL, an die Sie Cookies senden (oder
festlegen) ist unsicher. Das liegt daran, dass
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 vonhttps://
ws://
Verbindung vonhttp://
Websiteübergreifend:
wss://
Verbindung vonhttp://
ws://
Verbindung vonhttps://
Foto von Julissa Capdevilla am Unsplash