Bereit machen für die neuen Cookie-Einstellungen des Typs „SameSite=None; Secure“

Donnerstag, 16. Januar 2020

Dies ist ein Cross-Post aus dem Chromium-Entwicklerblog, der sich darauf bezieht, wie sich Änderungen in Chrome auf die zukünftige Funktionsweise eurer Website auswirken können.

Im Mai hat Chrome ein Secure-by-Default-Modell für Cookies angekündigt, das durch ein neues Cookie-Klassifizierungssystem (Spezifikation) aktiviert wird. Diese Initiative ist Teil unserer kontinuierlichen Bemühungen, den Datenschutz und die Sicherheit im Web zu verbessern.

Das neue Modell soll im Februar 2020 mit Chrome 80 implementiert werden. Auch Mozilla und Microsoft haben angegeben, dass sie die Implementierung des neuen Modells in Firefox und Edge planen. Die Chrome-Änderungen werden zwar erst in einigen Monaten umgesetzt. Trotzdem sollten Entwickler, die Cookies verwalten, sich am besten schon jetzt darauf vorbereiten. In diesem Blogpost werden die grundlegenden Konzepte erläutert. Nähere Informationen für Entwickler findet ihr auf der Website web.dev unter SameSite Cookies Explained.

In Websites sind in der Regel externe Dienste für Werbung, Inhaltsempfehlungen, Widgets von Drittanbietern, die Einbindung von sozialen Medien und andere Funktionen integriert. Beim Surfen im Internet können diese externen Dienste Cookies im Browser speichern und später auf diese Cookies zugreifen, um personalisierte Funktionen bereitzustellen oder die Interaktion mit Zielgruppen zu messen. Jedem Cookie ist eine Domain zugeordnet. Wenn die mit einem Cookie verknüpfte Domain zu einem externen Dienst gehört und nicht mit der Website in der Adressleiste des Nutzers übereinstimmt, wird das Cookie als websiteübergreifendes Cookie oder Drittanbieter-Cookie bezeichnet.

Zu den weniger offensichtlichen websiteübergreifenden Anwendungsfällen gehören Situationen, in denen ein Inhaber mehrerer Websites ein Cookie für alle Properties verwendet. Das Cookie und die Websites gehören zwar demselben Inhaber. Trotzdem gilt es als websiteübergreifender oder Drittanbieter-Kontext, wenn die Domain des Cookies nicht mit der oder den Websites übereinstimmt, von denen auf das Cookie zugegriffen wird.

Website-Domain stimmt nicht mit der Cookie-Domain überein

Wenn eine externe Ressource auf einer Webseite auf ein Cookie zugreift, das nicht mit der Website-Domain übereinstimmt, handelt es sich um ein websiteübergreifendes oder Drittanbieter-Cookie.

Stimmt die Domain eines Cookies dagegen mit der Website-Domain in der Adressleiste des Nutzers überein, ist es ein SameSite-Cookie oder Erstanbieter-Cookie. SameSite-Cookies werden häufig verwendet, damit die Nutzer bei einzelnen Websites angemeldet bleiben und um ihre Einstellungen zu speichern und Websiteanalysen zu unterstützen.

Website-Domain stimmt mit der Cookie-Domain überein

Wenn eine Ressource auf einer Webseite auf ein Cookie zugreift, das mit der Website übereinstimmt, die der Nutzer besucht, handelt es sich um ein SameSite- oder Erstanbieter-Cookie.

Wenn ein Cookie nur für den Zugriff in einem Erstanbieter-Kontext vorgesehen ist, können Entwickler heute eine der beiden Einstellungen SameSite=Lax oder SameSite=Strict anwenden, um externen Zugriff zu verhindern. Allerdings folgen nur wenige Entwickler dieser empfohlenen Vorgehensweise und setzen damit eine große Anzahl von SameSite-Cookies unnötig Bedrohungen wie CSRF-Angriffen (Cross-Site Request Forgery) aus.

Um Websites und Nutzer besser zu schützen, wird beim neuen Secure-by-Default-Modell davon ausgegangen, dass alle Cookies vor einem externen Zugriff geschützt sein sollten, sofern nicht anders angegeben. Entwickler müssen die neue Cookie-Einstellung SameSite=None verwenden, um Cookies für den websiteübergreifenden Zugriff zu bestimmen. Wenn das Attribut SameSite=None vorhanden ist, muss ein zusätzliches Secure-Attribut verwendet werden, damit websiteübergreifende Cookies nur über HTTPS-Verbindungen aufgerufen werden können. Dadurch werden zwar nicht alle Risiken im Zusammenhang mit dem websiteübergreifenden Zugriff vermieden, aber ein Schutz vor Netzwerkangriffen implementiert.

Abgesehen von den unmittelbaren Sicherheitsvorteilen sorgt die explizite Deklaration websiteübergreifender Cookies für mehr Transparenz und Flexibilität. Nutzern könnten so beispielsweise im Browser detaillierte Einstellungen angeboten werden, mit denen sich websiteübergreifende und SameSite-Cookies getrennt verwalten lassen.

Einsatz in Chrome ab Februar 2020

Mit der Einführung von Chrome 80 im Februar werden in Chrome Cookies, die keinen SameSite-Wert haben, als SameSite=Lax-Cookies behandelt. Nur Cookies mit der Einstellung „SameSite=None; Secure“ stehen dann für den externen Zugriff zur Verfügung, vorausgesetzt, der Zugriff erfolgt über sichere Verbindungen. Die Status-Tracker der Chrome-Plattform für SameSite=None und Secure werden weiterhin mit den neuesten Informationen über Neueinführungen aktualisiert.

Mozilla beabsichtigt, die Anforderungen von „SameSite=None; Secure“ für websiteübergreifende Cookies in Firefox zu implementieren und damit das neue Modell zur Cookieklassifizierung zu unterstützen. Auch Microsoft hat vor Kurzem angekündigt, mit der Implementierung des Modells versuchsweise in Microsoft Edge 80 zu beginnen.

Vorbereitung – bekannte Herausforderungen

Wenn ihr websiteübergreifende Cookies verwaltet, müsst ihr die Einstellung „SameSite=None; Secure“ auf diese Cookies anwenden. Die Implementierung sollte für die meisten Entwickler kein Problem darstellen. Wir empfehlen euch aber trotzdem, jetzt schon mit dem Testen zu beginnen, um mögliche Herausforderungen und Sonderfälle zu auszumachen. Hier einige Beispiele:

  • Nicht alle Sprachen und Bibliotheken unterstützen schon den Wert „None“. Entwickler müssen in diesem Fall den Cookie-Header direkt festlegen. In diesem GitHub-Repository findet ihr Anleitungen zur Implementierung von „SameSite=None; Secure“ in verschiedenen Sprachen, Bibliotheken und Frameworks.
  • Manche Browser, darunter einige Versionen von Chrome, Safari und UC Browser, verarbeiten den Wert None möglicherweise nicht wie gewünscht. Entwickler müssen dann Ausnahmen für diese Clients programmieren. Dazu gehört auch Android WebView, das auf älteren Chrome-Versionen basiert. Hier ist eine Liste bekannter inkompatibler Clients.
  • Auch wenn das neue Modell erst später in Android WebView implementiert wird, sollten App-Entwickler die entsprechenden SameSite cookie-Einstellungen für Android WebViews basierend auf Chrome-Versionen deklarieren, die mit dem Wert None kompatibel sind – sowohl für Cookies, auf die über HTTP(S)-Header zugegriffen wird, als auch für solche mit Zugriff über die CookieManager API von Android WebView.
  • IT-Administratoren in Unternehmen müssen möglicherweise spezielle Richtlinien implementieren, um den Chrome-Browser vorübergehend auf das alte Verhalten zurückzusetzen, wenn einige Dienste wie die Einmalanmeldung (SSO) oder interne Anwendungen noch nicht für die Einführung im Februar bereit sind.
  • Wenn ihr auf manche Cookies sowohl im Erst- als auch im Drittanbieterkontext zugreift, kann es sinnvoll sein, getrennte Cookies zu verwenden. So könnt ihr die Sicherheitsvorteile von SameSite=Lax im Erstanbieterkontext nutzen.

Unter SameSite Cookies Explained findet ihr spezifische Anleitungen für die oben genannten Situationen. Außerdem könnt ihr dort Probleme posten und Fragen stellen.

Wenn ihr die Auswirkungen des neuen Chrome-Verhaltens auf eure Website oder die von euch verwalteten Cookies testen möchtet, könnt ihr in Chrome 76+ die Seite chrome://flags aufrufen und die Tests „SameSite by default cookies“ und „Cookies without SameSite must be secure“ auswählen. Diese Tests werden außerdem für eine Untergruppe von Betanutzern von Chrome 79 automatisch aktiviert. Bei einigen Betanutzern, für die die Tests aktiviert sind, kann es zu Kompatibilitätsproblemen mit Diensten kommen, die das neue Modell noch nicht unterstützen. Diese Nutzer können die Betatests unter chrome://flags deaktivieren.

Wenn ihr ausschließlich SameSite-Cookies verwaltet, müsst ihr nichts weiter tun. Chrome verhindert dann automatisch den externen Zugriff auf diese Cookies, auch wenn das SameSite-Attribut fehlt oder kein Wert festgelegt ist. Wir empfehlen jedoch dringend, einen geeigneten SameSite-Wert („Lax“ oder „Strict“) anzuwenden und sich nicht auf das Standardverhalten des Browsers zu verlassen, da nicht alle Browser standardmäßig SameSite-Cookies schützen.

Wenn ihr euch fragt, ob externe Anbieter von Diensten für eure Website auf die Änderung vorbereitet sind, könnt ihr in Chrome 77+ die Entwicklertools-Konsole aufrufen. Dort findet ihr entsprechende Warnungen, wenn eine Seite websiteübergreifende Cookies ohne die erforderlichen Einstellungen enthält:

Ein Cookie, das einer websiteübergreifenden Ressource auf (Cookie-Domain) zugeordnet ist, wurde ohne das Attribut „SameSite“ definiert

Manche Anbieter, darunter auch einige Google-Dienste, implementieren die erforderlichen Änderungen in den Monaten vor der Einführung von Chrome 80 im Februar. Wendet euch gegebenenfalls an eure Partner, um sicherzugehen, dass sie richtig vorbereitet sind.

Gepostet von Barb Palser, Chrome and Web Platform Partnerships