SameSite-Cookies erklärt

Sichern Sie Ihre Website, indem Sie lernen, wie Sie Ihre Cross-Site-Cookies explizit kennzeichnen.

May 7, 2019 — Updated May 28, 2020

Available in: English, Español, Français, Português, Русский, 中文, 日本語, and 한국어

Appears in: Safe and secure

Rowan Merewood

TwitterGitHubGlitch

Cookies sind eine der verfügbaren Methoden, um Websites einen dauerhaften Status hinzuzufügen. Im Laufe der Jahre haben ihre Funktionen zugenommen und sie sind weiterentwickelt worden, wobei allerdings auch einige problematische Altlasten für die Plattform entstanden sind. Um dem entgegenzuwirken, ändern Browser (einschließlich Chrome, Firefox und Edge) ihr Verhalten und setzen datenschutzfreundlichere Standardeinstellungen durch.

Jedes Cookie ist ein key=value-Paar mit einer Reihe von Attributen, die steuern, wann und wo dieses Cookie verwendet wird. Sie haben diese Attribute wahrscheinlich bereits verwendet, um Dinge wie Ablaufdaten festzulegen oder anzugeben, dass das Cookie nur über HTTPS gesendet werden soll. Server setzen Cookies, indem sie in ihrer Antwort den treffend benannten Set-Cookie-Header senden. Für alle Details können Sie sich das Dokument RFC6265bis durchlesen, aber hier vorerst eine kurze Erinnerung.

Angenommen, Sie haben einen Blog, in dem Sie Ihren Benutzern eine „Neuigkeiten“-Werbeaktion anzeigen möchten. Benutzer können die Werbeaktion ausblenden und sehen sie dann für eine Weile nicht mehr. Sie können diese Einstellung in einem Cookie speichern, den sie in einem Monat (2.600.000 Sekunden) ablaufen lassen und eine Übertragung ausschließlich über HTTPS zulassen. Dieser Header würde so aussehen:

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

Wenn sich Ihre Besucher eine Seite ansehen, die diese Anforderungen erfüllt, z. B. wenn eine sichere Verbindung besteht und das Cookie weniger als einen Monat alt ist, senden die Browser diesen Header in der Anfrage:

Cookie: promo_shown=1

Sie können die für diese Site verfügbaren Cookies auch per JavaScript mit document.cookie hinzufügen und lesen. Durch eine Zuweisung an document.cookie wird ein Cookie mit diesem Schlüssel erstellt oder überschrieben. Sie können beispielsweise Folgendes in der JavaScript-Konsole Ihres Browsers versuchen:

→ document.cookie = "promo_shown=1; Max-Age=2600000; Secure"
← "promo_shown=1; Max-Age=2600000; Secure"

Beim Lesen von document.cookie werden alle im aktuellen Kontext zugänglichen Cookies ausgegeben, wobei jedes Cookie durch ein Semikolon getrennt ist:

→ document.cookie;
← "promo_shown=1; color_theme=peachpuff; sidebar_loc=left"

Wenn Sie dies auf einer Auswahl beliebter Websites ausprobieren, werden Sie feststellen, dass die meisten von ihnen deutlich mehr als nur drei Cookies setzen. In den meisten Fällen werden diese Cookies bei jeder einzelnen Anfrage an eine dieser Domains gesendet, was eine Reihe von Auswirkungen hat. Die Upload-Bandbreite Ihrer Benutzer ist oft stärker eingeschränkt als die Download-Bandbreite, sodass der Overhead für alle ausgehenden Anfragen die Zeit bis zum ersten empfangenen Byte verzögert. Gehen Sie beim Festlegen der Anzahl und Größe der von Ihnen gesetzten Cookies zurückhaltend vor. Verwenden Sie das Max-Age-Attribut, um sicherzustellen, dass Cookies nicht länger als nötig vorhanden bleiben.

Was sind Erstanbieter- und Drittanbieter-Cookies? #

Wenn Sie einer Auswahl von Webseiten zurückkehren, die Sie bereits zuvor besucht haben, dann ist Ihnen wahrscheinlich aufgefallen, dass Cookies für eine Vielzahl von Domains vorhanden sind, und nicht nur für die, die Sie gerade besuchen. So werden Cookies für die Domain der aktuell besuchten und in der Adresszeile des Browsers angezeigten Seite, als Erstanbieter-Cookies bezeichnet. Cookies von anderen Domains als der aktuellen Webseite werden als Drittanbieter-Cookies bezeichnet. Dies sind keine absoluten Bezeichnungen, sondern sie sind relativ zum Kontext des Benutzers aufzufassen. Ein und derselbe Cookie kann entweder ein Erstanbieter- oder ein Drittanbieter-Cookie sein, je nachdem, auf welcher Website sich der Benutzer gerade befindet.

Führen wir einmal das oben angefangene Beispiel weiter, und nehmen an, einer Ihrer Blog-Posts würde unter /blog/img/amazing-cat.png gehostet und ein Bild einer besonders tollen Katze enthalten. Weil es ein so tolles Bild ist, verwendet es eine andere Person direkt auf ihrer eigenen Website. Wenn ein Besucher Ihren Blog besucht hat und der Cookie die promo_shown vorhanden ist, dann wird, wenn sie amazing-cat.png auf der Website der anderen Person betrachten, das Cookie für das Bild in der Anfrage mitübertragen. Dies ist für niemanden besonders nützlich, da promo_shown für nichts auf der Webseite dieser anderen Person verwendet wird, es fügt der Anfrage lediglich Overhead hinzu.

Wenn dies also ein unbeabsichtigter Effekt ist, warum sollten Sie das tun? Dieser Mechanismus ermöglicht es Webseiten, Ihren Zustand beizubehalten, wenn sie in einem Drittanbieterkontext verwendet werden. Wenn Sie beispielsweise ein YouTube-Video auf Ihrer Website einbetten, sehen Besucher im Player die Option „Später ansehen“. Ist Ihr Besucher bereits bei YouTube angemeldet, wird diese Sitzung im eingebetteten Player durch einen Drittanbieter-Cookie zur Verfügung gestellt. Dies bedeutet, dass die Schaltfläche „Später ansehen“ das Video in einem Schritt speichert, anstatt ihn zur Anmeldung aufzufordern oder von Ihrer Seite weg zu YouTube zu navigieren.

Eine der kulturellen Eigenschaften des Webs ist, dass es in der Regel offen ist. Dies ist einer der Gründe, aus denen so vielen Menschen ermöglicht wurde, dort ihre eigenen Inhalte und Apps zu erstellen. Andererseits hat dies jedoch auch eine Reihe von Sicherheits- und Datenschutzbedenken mit sich gebracht. Cross-Site Request Forgery-Angriffe (CSRF) beruhen darauf, dass Cookies für alle Anfragen mit beliebigen Zielen angehängt werden, unabhängig davon, wer diese Anfragen initiiert. Wenn Sie beispielsweise evil.example besuchen, kann diese Seite Anfragen für your-blog.example auslösen und Ihr Browser würde dazu ohne weiteres die zugehörigen Cookies anhängen. Wenn Ihr Blog also nicht sicherstellt, dass diese Anfragen korrekt validiert werden, dann kann evil.example Aktionen wie das Löschen von Beiträgen oder das Hinzufügen eigener Inhalte auslösen.

Benutzer werden sich auch immer mehr bewusst, wie Cookies verwendet werden können, um ihre Aktivitäten über mehrere Webseiten nachzuverfolgen. Bisher gab es für Sie jedoch keine Möglichkeit, Ihre Absicht mit dem Cookie explizit anzugeben. Ihr promo_shown-Cookie sollte nur in einem Erstanbieterkontext gesendet werden, während mit einem Sitzungscookie für ein Widget, das auf anderen Webseiten eingebettet werden soll, eine klare Absicht besteht, den Anmeldestatus in einem Drittanbieterkontext bereitzustellen.

Geben Sie die Cookie-Verwendung explizit mit dem Attribut SameSite an #

Durch die Einführung des SameSite-Attributs (definiert in RFC6265bis) können Sie angeben, ob die Verwendung Ihres Cookies auf einen Erstanbieter- oder Same-Site-Kontext beschränkt werden soll. Es ist hilfreich, genau zu verstehen, was „Site“ hier bedeutet. Die Site ist die Kombination aus dem Domain-Suffix und dem Teil der Domain direkt davor. So ist beispielsweise die Domain www.web.dev Teil der web.dev-Site.

Dies wird mithilfe der öffentlichen Suffixliste definiert, die nicht nur Top-Level-Domains wie .com, sondern auch Dienste wie github.io enthält. So wird es ermöglicht, dass your-project.github.io und my-project.github.io als separate Sites betrachtet werden können.

Die Einführung des SameSite Attributs in ein Cookie bietet drei verschiedene Möglichkeiten, dieses Verhalten zu steuern. Sie können das Attribut nicht angeben, oder Sie können Strict oder Lax , um das Cookie auf Anfragen derselben Site zu beschränken.

Wenn Sie SameSite auf Strict stellen, wird Ihr Cookie nur in einem Erstanbieterkontext gesendet. Aus Benutzersicht wird das Cookie nur gesendet, wenn die Site für das Cookie mit der Site übereinstimmt, die derzeit in der URL-Leiste des Browsers angezeigt wird. Wenn also das promo_shown-Cookie wie folgt eingestellt wurde:

Set-Cookie: promo_shown=1; SameSite=Strict

Wenn der Benutzer sich auf Ihrer Website aufhält, wird das Cookie wie erwartet mit der Anfrage gesendet. Wenn Sie jedoch einem Link zu Ihrer Site folgen, beispielsweise von einer anderen Site oder über eine E-Mail von einem Freund, wird bei dieser ersten Anfrage kein Cookie gesendet. Dies ist gut, wenn es um Cookies geht, die sich auf Funktionen beziehen, denen immer eine vorherige Navigation vorausgeht, wie zum Beispiel das Ändern eines Passworts oder eine Bestellung, ist jedoch zu restriktiv für promo_shown. Wenn Ihr Leser dem Link auf die Site folgt, möchte er, dass das Cookie gesendet wird, damit seine Präferenz angewendet werden kann.

Hier kommt SameSite=Lax zum Zug, indem es erlaubt, dass das Cookie bei dieser Top-Level-Navigation mitgesendet wird. Sehen wir uns das Beispiel mit der Katze aus dem oben stehenden Artikel noch einmal an, bei dem eine andere Website auf Ihren Inhalt verweist. Sie verwenden Ihr Foto der Katze direkt und stellen einen Link zu Ihrem ursprünglichen Artikel bereit.

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

Und das Cookie wurde so gesetzt:

Set-Cookie: promo_shown=1; SameSite=Lax

Wenn sich der Leser im Blog der anderen Person befindet, wird das Cookie nicht gesendet, wenn der Browser amazing-cat.png anfordert. Wenn der Leser jedoch dem Link zu cat.html in Ihrem Blog folgt, enthält diese Anfrage das Cookie. Dies macht Lax zu einer guten Wahl für Cookies, die das Aussehen einer Website betreffen, wobei Strict für Cookies nützlich ist, die Nutzeraktionen betreffen.

Schließlich besteht die Möglichkeit, den Wert nicht anzugeben, was bislang implizit bedeutete, dass das Cookie in allen Kontexten gesendet werden soll. Im neuesten Entwurf von RFC6265bis wird dies durch die Einführung eines neuen Wertes von SameSite=None explizit festgelegt. Das bedeutet, dass Sie mit None klar kommunizieren können, dass Sie das Cookie absichtlich im Drittanbieterkontext senden möchten.

Änderungen am Standardverhalten ohne SameSite #

Obwohl das SameSite-Attribut weithin unterstützt wird, wird es leider nicht von vielen Entwicklern genutzt. Die offene Standardeinstellung, mit der Cookies überall hingesendet werden können, sichert zwar in allen Anwendungsfällen die Funktion, aber die Benutzer sind anfällig für CSRF und unbeabsichtigte Informationslecks. Um Entwickler zu ermutigen, ihre Absicht zu äußern und den Benutzern ein sichereres Erlebnis zu bieten, enthält der IETF-Vorschlag Incrementally Better Cookies zwei wichtige Änderungen:

• Cookies ohne SameSite-Attribut werden wie solche mit dem Attribut SameSite=Lax behandelt.
• Cookies mit SameSite=None müssen auch Secure angeben, sie erfordern also einen sicheren Kontext.

Chrome implementiert dieses Standardverhalten ab Version 84. Firefox stellt sie zum Testen ab Firefox 69 bereit und wird sie in Zukunft zum Standardverhalten machen. Um dieses Verhalten in Firefox zu testen, öffnen Sie about:config und legen Sie network.cookie.sameSite.laxByDefault fest. Auch für Edge ist geplant, das Standardverhalten zu ändern.

SameSite=Lax in der Standardeinstellung #

Set-Cookie: promo_shown=1

Set-Cookie: promo_shown=1; SameSite=Lax

Obwohl dies als eine sicherere Standardeinstellung gedacht ist, sollten Sie idealerweise dennoch ein explizites SameSite-Attribut festlegen, anstatt sich darauf zu verlassen, dass der Browser dieses für Sie anwendet. Dies macht Ihre Absicht für das Cookie deutlich und verbessert die Chancen auf ein übereinstimmendes Benutzererlebnis in allen Browsern.

SameSite=None muss sicher sein #

Set-Cookie: widget_session=abc123; SameSite=None

Set-Cookie: widget_session=abc123; SameSite=None; Secure

Sie können dieses Verhalten ab Chrome 76 testen, indem Sie about://flags/#cookies-without-same-site-must-be-secure aktivieren und ab Firefox 69 unter about:config die Einstellung network.cookie.sameSite.noneRequiresSecure setzen.

Sie sollten diese Einstellungen beim Setzen neuer Cookies anwenden und vorhandene Cookies aktiv aktualisieren, auch wenn deren Ablaufdatum noch in der Ferne liegt.

Beide Änderungen sind abwärtskompatibel mit Browsern, die die vorherige Version des SameSite-Attributs korrekt implementiert haben oder es überhaupt nicht unterstützen. Indem Sie diese Änderungen auf Ihre Cookies anwenden, erklären Sie explizit deren beabsichtigte Verwendung, anstatt sich auf das Standardverhalten des Browsers zu verlassen. Ebenso sollten alle Clients, die SameSite=None noch nicht erkennen, es einfach ignorieren und weiterarbeiten, als ob das Attribut nicht gesetzt wäre.

SameSite-Cookie-Rezepte #

Weitere Informationen dazu, wie Sie Ihre Cookies genau aktualisieren, um diese Änderungen zu SameSite=None und den einhergehenden Unterschied im Browserverhalten zu berücksichtigen, finden Sie im Folgeartikel SameSite-Cookie-Rezepte .

Herzlichen Dank für Beiträge und Feedback von Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner und Vivek Sekhar

Cookie-Held-Bild von Pille-Riin Priske auf Unsplash