Cookies - SameSite Attribute

Photo by Mohammad Rahmani on Unsplash

Ab Version 84 setzt Chrome das SameSite-Attribut von Cookies standardmäßig auf Lax. Dienste, die Third-party Cookies verwenden, können betroffen sein, wenn sie SameSite nicht richtig konfiguriert haben.

Überblick

Cookies sind Mechanismen, die in Webdiensten verwendet werden, um Status zu speichern, häufig genutzt für die Aufrechterhaltung von Login-Sitzungen, Warenkörben, Anzeigenverfolgung usw. Die weit verbreitete Verwendung von Cookies bringt jedoch auch Datenschutz- und Sicherheitsbedenken mit sich, und SameSite wurde eingeführt, um diese Probleme anzugehen.

First-Party und Third-Party

Basierend auf der Quelle des Cookies (Set-Cookie) hat jedes Cookie eine spezifische Domain. Wenn man die aktuelle URL im Browser des Benutzers betrachtet, ist es First-Party, wenn die Domain des Cookies mit der aktuellen URL übereinstimmt; andernfalls ist es Third-Party.

Third-Party

Wenn Sie beispielsweise die Website a.com durchsuchen, eine Anfrage (Request) an third-party.com senden und ein Cookie von third-party.com erhalten. Da der Browser Cookies mit derselben Domain automatisch in Anfragen einschließt, erhält der Server das Cookie, wenn Sie später eine andere Website wie b.com durchsuchen und diese ebenfalls eine Anfrage an third-party.com sendet. Für diese beiden Websites ist das Cookie von third-party.com Third-Party.

First-Party

Wenn Sie eine Website besuchen, die mit der Domain third-party.com übereinstimmt, wird das Cookie ebenfalls gesendet. In diesem Fall wird dieses Cookie First-Party genannt.

Same-Origin und Same-Site

Das vorherige Beispiel erwähnte die Verwendung der Domain zur Bestimmung des Cookie-Typs, aber eine bessere Art, es auszudrücken, ist zu bestimmen, ob die Site (Website) dieselbe ist. Hängt dies mit dem häufig gesehenen Same-Origin zusammen?

Cookies SameSite

Origin

Origin besteht aus Schema, Host und Port. Die Bestimmungsmethode ist sehr einfach: Wenn Schema, Host und Port von zwei URLs alle identisch sind, sind sie Same-Origin; andernfalls sind sie Cross-Origin.

Site

Die Bestimmung von Same-Site bezieht Effective Top-Level Domains (eTLDs) ein. Alle eTLDs sind in der Public Suffix List definiert, und eine Site besteht aus einer eTLD plus einem Präfix.

Zum Beispiel: github.io existiert in der Public Suffix List. Das Hinzufügen eines Präfixes (z. B. a.github.io) macht es zu einer Site. Daher sind a.github.io und b.github.io zwei verschiedene Sites (Cross-Site).

example.com existiert nicht in der Public Suffix List, aber .com schon, also ist example.com eine Site, und a.example.com und b.example.com sind dieselbe Site (Same-Site).

Beachten Sie, dass Site den Port nicht einschließt, sodass sie auch bei unterschiedlichen Ports Same-Site sein können.

Warum SameSite?

Der Mechanismus, bei dem “jede Anfrage Cookies dieser Domain trägt”, brachte auch Sicherheitsprobleme und andere Probleme mit sich, wobei das wichtigste Cross-Site Request Forgery (CSRF) ist.

CSRF

Angenommen, ein Benutzer hat sich bei example.com angemeldet und ein Cookie erhalten. Wenn der Benutzer eine bösartige Website evil.com besucht, kann JavaScript auf dieser Website eine POST-Anfrage an example.com/pay?amount=1000 senden. Der Browser schließt das Cookie von example.com automatisch ein, und der Benutzer zahlt unwissentlich 1000 Dollar. Der Server kann nicht feststellen, woher diese Anfrage (Request) kam.

Einschränkungen

Cookies selbst können nicht so eingestellt werden, dass sie nur in einer First-Party-Umgebung gesendet werden, sodass Anfragen Cookies in jeder Umgebung tragen. Der Server kann die Quelle der Anfrage nicht identifizieren und kann nur wie gewohnt antworten, was dazu führt, dass der Client Bandbreite verschwendet, um nutzlose Cookies zu senden.

Lösung

Mit dem SameSite-Attribut können wir die Bedingungen für das Senden von Cookies in verschiedenen Umgebungen individuell konfigurieren.

SameSite

Das SameSite-Attribut hat drei Werte. Wenn Sie es auf Strict oder Lax setzen, können Sie Cookies so einschränken, dass sie nur in Same-Site-Anfragen gesendet werden. Wenn es leer gelassen wird, hängt das Verhalten vom Browser ab; für Chrome ist der Standardwert Lax.

Strict

Cookies werden nur in einer First-Party-Umgebung gesendet. Es gibt jedoch ein Problem: Angenommen, ein Benutzer sieht einen Facebook-Beitragslink auf example.com (sagen wir fb.com). Selbst wenn der Benutzer bei fb.com angemeldet ist und ein Cookie hat, wird das Klicken auf den Link das Cookie nicht senden, da die beiden Websites Cross-Site sind, sodass er nur die Login-Seite sieht.

Daher ist Strict für sensible Aktionen geeignet, wie z. B. Beiträge löschen, Zahlungen tätigen usw.

Lax

Um die übermäßig strengen Einschränkungen von Strict zu beheben, erlaubt Lax das Senden von Cookies auch in Cross-Site-Situationen in den folgenden Fällen:

Eingabe einer URL in die Adressleiste
Klicken auf einen Link <a href="...">
Senden eines Formulars <form method="GET">
Vorabrendern (Prerendering) <link rel="prerender" href="...">

Diese Fälle haben zwei Gemeinsamkeiten: Es sind alle GET-Anfragen und sie lösen alle eine Top-Level-Navigation (Top-level Navigation) aus. Dies vermeidet das Problem, dass Strict jedes Mal eine erneute Anmeldung erfordert, und verhindert auch das unwissentliche Senden von Cookies beim Durchsuchen anderer Websites.

Lax + POST

Um jedoch einige bestehende Anmeldeabläufe nicht zu unterbrechen, lockert Chrome derzeit die Einschränkung für SameSite=Lax geringfügig, um Entwicklern mehr Zeit zur Anpassung zu geben.

Innerhalb von zwei Minuten nach dem Setzen des Cookies wird das Cookie gesendet, unabhängig von der Anfragemethode (Request Method), solange es eine Top-Level-Seitennavigation auslöst. Das bedeutet, wenn der Browser die Seite wechselt, z. B. durch Senden eines Formulars <form method="POST">.

Details finden Sie im Thread über Lax + POST.

None

Um ein Third-party Cookie zu senden, müssen Sie SameSite=None; Secure setzen. Ja, ab sofort, wenn Sie ein Third-party Cookie in einer Testumgebung senden möchten, bereiten Sie bitte https://localhost vor.

Darüber hinaus erfordert das Senden von Cross-Origin Requests über XHR/Fetch die Einstellung von withCredentials: true, um das Cookie zu senden und den Set-Cookie im Antwort-Header wirksam zu machen. Der Server muss auch Access-Control-Allow-Credentials: true im Antwort-Header setzen, damit JavaScript auf den Antwortinhalt zugreifen kann.

Nicht unterstützte Browser

Noch unterstützen nicht alle Browser die neuesten SameSite-Regeln, daher können einige vorübergehende Problemumgehungen (Workarounds) auf dem Server hinzugefügt werden, um mehrere Browser zu unterstützen:

Beide Cookies setzen

Diese Methode kann Probleme für fast alle Browser lösen, aber der Nachteil ist, dass es zwei Kopien des Cookies geben wird:

Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure

Serverseitiger Code:

if (req.cookies['name']) {
  // Verwenden Sie das neue, falls verfügbar
  cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
  // Andernfalls verwenden Sie das alte
  cookieVal = req.cookies['name-legacy'];
}

User Agent

Bestimmen Sie den Browser anhand des User Agents der Anfrage, um den Inhalt von Set-Cookie zu entscheiden. Diese Methode erfordert nur eine Änderung des Codes, der das Cookie setzt, ohne den Parsing-Teil zu ändern. Diese Beurteilungsmethode beinhaltet jedoch mehr Variablen und macht es einfacher, das falsche Cookie zu setzen.

Rückblick

Cookies ohne gesetztes SameSite-Attribut werden standardmäßig auf SameSite=Lax gesetzt und können in einer Cross-Site-Umgebung nicht gesendet werden.
Um Cookies in Cross-Site zu senden, müssen Sie SameSite=None; Secure setzen.
Sie können die SameSite Sandbox verwenden, um zu testen, ob Ihr aktueller Browser den neuesten SameSite-Regeln entspricht.