Freigeben über

Cookies und lokaler Speicher

  • Artikel

Cookies sind Textzeichenfolgen, die von Websites gesendet und vom Webbrowser auf einem Computer gespeichert werden. Sie werden für die Authentifizierung und Personalisierung verwendet. Cookies werden beispielsweise verwendet, um Statusinformationen abzurufen, Benutzereinstellungen beizubehalten, Browseraktivitäten aufzuzeichnen und relevante Werbeanzeigen einzublenden. Cookies sind immer mit einer bestimmten Domäne verknüpft und werden von verschiedenen Parteien installiert.

Arten von Cookies

Arten von Cookies und entsprechende Anwendungsbereiche:

Cookie Bereich
Cookies von Erstanbietern Ein Erstanbieter-Cookie wird von Websites erstellt, die ein Benutzer besucht. Es wird zum Speichern von Daten wie Warenkorbartikeln und Anmeldeinformationen verwendet. Dazu gehören beispielsweise Authentifizierungscookies und andere Analyse-Cookies.
Zweitparteien-Cookies Ein Zweitparteien-Cookie ist technisch gesehen dasselbe wie ein Erstanbieter-Cookie. Der Unterschied besteht darin, dass Daten auf der Grundlage einer Datenpartnerschaftsvereinbarung an eine zweite Partei übermittelt werden. Beispielsweise für Microsoft Teams–Analysen und -Berichte.
Cookies von Drittanbietern Ein Drittanbieter-Cookie wird von einer anderen Domäne als der, die der Benutzer explizit besucht hat, installiert und für die Nachverfolgung verwendet. Beispiele: Gefällt mir-Schaltflächen, Werbeanzeigen und Live-Chats.

Cookies und HTTP-Anforderungen

Vor der Einführung der SameSite-Einschränkungen wurden die Cookies im Browser gespeichert. Sie wurden an jede HTTP-Webanforderung angefügt und über den Set Cookie-HTTP-Antwortheader an den Server gesendet. Dadurch wurden Sicherheitslücken eingeführt, z. B. siteübergreifende Anforderungsfälschungen, die als CSRF-Angriffe bezeichnet werden. Durch die SameSite-Komponente wurde dieses Risiko verringert dank deren Implementierung und Verwaltung im SetCookie-Header.

Die SetCookie SameSite-Spezifikation wurde als optionales Attribut in Google Chrome Version 51 eingeführt. Ab Build 17672 Windows 10 sameSite-Cookieunterstützung für den Microsoft Edge-Browser eingeführt.

Sie können das Hinzufügen des SameSite-Cookieattributs zum SetCookie-Header deaktivieren oder es mit einer von zwei Einstellungen hinzufügen, Lax und Strict. Ein nicht implementiertes SameSite-Attribut wurde als Standardzustand betrachtet.

In Chrome 80, veröffentlicht im Februar 2020, wurden neue Cookie-Werte eingeführt und es werden standardmäßig Cookie-Richtlinien erzwungen. Drei Werte werden im aktualisierten SameSite-Attribut übergeben: Strict, Lax oder None. Wenn nicht angegeben, verwendet das SameSite-Attribut von Cookies standardmäßig den Wert SameSite=Lax.

SameSite-Cookieattribute:

Einstellung Erzwingung Wert Attributspezifikation
Lax Cookies werden automatisch nur in einem Erstanbieterkontext und mit HTTP GET-Anforderungen gesendet. SameSite-Cookies werden bei websiteübergreifenden Unteranforderungen wie Aufrufen zum Laden von Bildern oder iframeszurückgehalten. Sie werden gesendet, wenn ein Benutzer von einer externen Website aus zu der URL navigiert, z. B. durch Folgen eines Links. Default Set-Cookie: key=value; SameSite=Lax
Streng Der Browser sendet Cookies nur für Erstanbieter-Kontextanforderungen. Dies sind Anforderungen, die von der Website stammen, von der das Cookie abgelegt wurde. Wenn die Anforderung von einer anderen URL als jener der aktuellen Site stammt, werden keine der mit dem Strict-Attribut getaggten Cookies gesendet. Optional Set-Cookie: key=value; SameSite=Strict
Keine Cookies werden sowohl im Erstanbieterkontext als auch im cross origin requests gesendet; Der Wert muss jedoch explizit auf None festgelegt werden, und alle Browseranforderungen müssen dem HTTPS-Protokoll folgen und das Secure -Attribut enthalten, das eine verschlüsselte Verbindung erfordert. Cookies, die diese Anforderung nicht erfüllen, werden abgelehnt.
Beide Attribute sind zusammen erforderlich. Wenn None ohne Secure angegeben wird oder wenn das HTTPS-Protokoll nicht verwendet wird, werden die Cookies von Drittanbietern abgelehnt.		 Optional, aber falls festgelegt, ist das HTTPS-Protokoll erforderlich. Set-Cookie: key=value; SameSite=None; Secure

Auswirkungen und Anpassungen in Microsoft Teams

  1. Aktivieren Sie die entsprechende SameSite-Einstellung für Ihre Cookies, und überprüfen Sie dann, ob Ihre Apps und Erweiterungen in Microsoft Teams weiterhin funktionieren.
  2. Wenn bei Ihren Apps oder Erweiterungen Fehler auftreten, nehmen Sie die erforderlichen Korrekturen vor der Chrome 80-Version vor.
  3. Interne Microsoft-Partner können dem folgenden Team beitreten, um weitere Informationen oder Hilfe bei diesem Problem zu erhalten: https://teams.microsoft.com/l/team/19%3A08b594cd465e4c0491fb751e823802e2%40thread.skype/conversations?groupId=4d6d04cd-dbf0-43c8-a2ff-f80dd38be034& tenantId=aaaabbbb-0000-cccc-1111-dddd2222eeeeee.

Hinweis

Sie müssen SameSite-Attribute entsprechend der beabsichtigten Verwendung Ihrer Cookies festlegen. Verlassen Sie sich nicht auf das Standardverhalten von Browsern. Weitere Informationen finden Sie unter Entwickler: Machen Sie sich bereit für neue sichere Cookie-Einstellungen mit SameSite=None.

Registerkarten, Dialoge und Nachrichtenerweiterungen

  • In Microsoft Teams-Registerkarten werden <iframes> verwendet, um Inhalte einzubetten, die in einem Kontext der obersten Ebene oder des Erstanbieters angezeigt werden.
  • Mithilfe von Dialogen (in TeamsJS v1.x als Aufgabenmodule bezeichnet) können Sie modale Popupfunktionen in Ihrer Teams-Anwendung erstellen. Ähnlich wie bei einer Registerkarte wird innerhalb der aktuellen Seite ein modales Fenster geöffnet.
  • Mithilfe von Nachrichtenerweiterungen können Sie vielfältige Inhalte aus externen Ressourcen in eine Chatnachricht einfügen.

Cookies, die von eingebetteten Inhalten verwendet werden, werden als Drittanbieter-Cookies betrachtet, wenn die Website in einem <iframe> angezeigt wird. Wenn Remote-Ressourcen auf einer Seite darauf angewiesen sind, dass Cookies mit einer <img>-Anforderung und <script>-Tags, externen Schriftarten und personalisierten Inhalten gesendet werden, müssen Sie sicherstellen, dass diese für die websiteübergreifende Nutzung gekennzeichnet sind, z. B. SameSite=None; Secure, oder sicherstellen, dass ein Fallback vorhanden ist.

Authentifizierung

Sie müssen den webbasierten Authentifizierungsablauf für Folgendes verwenden:

  • Eingebettete Inhaltsseiten in Registerkarten
  • Konfigurationsseite, Dialogfeld und Nachrichtenerweiterung.
  • Konversationsbot mit einem Dialog.

Gemäß den aktualisierten SameSite-Einschränkungen fügt ein Browser einer bereits authentifizierten Website kein Cookie hinzu, wenn der Link von einer externen Website abgeleitet ist. Sie müssen sicherstellen, dass Ihre Authentifizierungscookies für die websiteübergreifende Nutzung gekennzeichnet sind (SameSite=None; Secure) oder dass ein Fallback vorhanden ist.

Android System WebView

Android WebView ist eine Chrome-Systemkomponente, mit der Android-Apps Webinhalte anzeigen können. Obwohl die neuen Einschränkungen ab Chrome 80 standardmäßig sind, werden sie nicht sofort für WebViews erzwungen. Sie werden in Zukunft angewendet. Zur Vorbereitung ermöglicht Android nativen Apps, Cookies direkt über die CookieManager-API festzulegen.

Hinweis

  • Sie müssen Cookies von Erstanbietern als SameSite=Lax oder SameSite=Strict deklarieren.
  • Sie müssen Cookies von Drittanbietern als SameSite=None; Securedeklarieren.

Veraltete Cookies von Drittanbietern

Cookies von Drittanbietern werden derzeit in allen gängigen Browsern als veraltet gekennzeichnet. Alle Cookies von Drittanbietern, die in der Domäne der obersten Ebene festgelegt sind, werden blockiert, wenn diese Domäne in eine iframeeingebettet ist.

Diese Einstellung wirkt sich auf ein häufiges Szenario aus, in dem die externe App in Teams an verschiedenen Einstiegspunkten gerendert wird, einschließlich persönlicher Apps, Kanalregisterkarten und Unterhaltungsregisterkarten, über Web-, Desktop- und mobile Teams-Clients hinweg.

Popupauthentifizierungsszenario

Popout-Authentifizierungsszenarien sind eine gängige Methode für Apps zur Authentifizierung mit verschiedenen Identitätsanbietern, z. B. einer externen Authentifizierung. So funktioniert das:

  1. Das gerenderte iframe löst ein Popup aus, das die anmeldeseite des ausgewählten Authentifizierungsanbieters lädt.
  2. Nachdem sich der Benutzer angemeldet hat, leitet das Popup an die Domäne der öffnenden App um, in der ein Authentifizierungscookies festgelegt ist, und das Popup wird geschlossen.
  3. Diese Cookies werden innerhalb des eingebetteten iframe verwendet, um den Benutzer zu authentifizieren.

Die Pop-out-Authentifizierung ist aus folgenden Gründen nicht von der Einstellung von Cookies von Drittanbietern betroffen:

  • Chromium-basierte Browser wie Google Chrome und Microsoft Edge ermöglichen den Zugriff auf Cookies, die nicht partitioniert, sicher und SameSite=Nonesind. Dies gilt, wenn die Cookies in einem Popupfenster von iframe festgelegt werden, um im iframezugänglich zu sein.

  • Browser, die nicht Chromium sind, z. B. Firefox, richten ihre Veraltetkeit von Cookies mit Chromium-basierten Browsern aus.

Die App simuliert dieses Szenario. So verwenden Sie eine App mit Cookies:

  1. Laden Sie Ihre App hoch, und öffnen Sie sie in einem iframe.

  2. Wählen Sie Partitionierte Cookies aus.

    Screenshots zeigen die partitionierten Cookies in der Cookies-App.

  3. Wählen Sie die Schaltfläche popOutApp aus, um sie als Erstanbieterdomäne aufzuklappen.

    Screenshot: Option

  4. Wählen Sie Partitionierte Cookies in der API festlegen aus.

    Screenshot: Festlegen von partitionierten Cookies über die API

    Jetzt können Sie im Teams-Fenster zur Registerkarte "Cookies" navigieren und sehen, dass nur partitioned:false Cookies und secure:true verfügbar sind:

    Screenshot: Registerkarte

Diese Aktion legt mehrere Cookies mit einer Kombination aus secure-, SameSite- und partitionierten Attributen fest. Nur SameSite=Nonesichere und nicht partitionierte Cookies sind innerhalb von iframezugänglich.

Der folgende Screenshot zeigt die Cookies, auf die im eingebetteten iframe zugegriffen werden kann, wenn sie über das Popupfenster der obersten Ebene der iframeURL festgelegt werden:

Screenshot: Cookies-App von Drittanbietern in Microsoft Teams

Erforderliche Aktionen für cookies set by iframe

Die folgende Tabelle hilft Ihnen beim Konfigurieren des Werts von partitionierten Attributen, um Cookies für eingebettete Elemente iframefestzulegen:

Festlegen von Cookies für eingebettete iframe Wert des Attributs partitioned
Wenn Cookies außerhalb des iframe gesetzt werden müssen, aber sie müssen innerhalb des iframe zugänglich sein. Legen Sie sie auf fest false.
Wenn Cookies innerhalb der iframe Sie können es auf oder falsetruefestlegen, je nachdem, ob Sie CHIPS (Cookies mit unabhängigem partitioniertem Zustand) für Cookies aktivieren möchten.

Hinweis

Sie müssen das partitioned Attribut entweder auf true oder false festlegen, um sicherzustellen, dass das Cookie festgelegt wird.

Speicherpartitionierung

Die Speicherpartitionierung ist vollständig in Google Chrome implementiert. Dies impliziert, dass im Erstanbieterkontext festgelegter lokaler Speicher nicht im Kontext von Drittanbietern innerhalb von iframes zugegriffen werden kann und umgekehrt.

Diese Änderung kann Szenarien wie die externe Authentifizierung in Browsern stören. Dies kann passieren, wenn daten im lokalen Speicher des Erstanbieterkontexts gespeichert werden. Danach kann auch der Zugriff auf diese Daten im Drittanbieterkontext beeinträchtigt werden. Weitere Informationen finden Sie unter Speicherpartitionierung.

Codebeispiel

Beispielname Beschreibung Node.js
Teams-Cookie-App Diese Beispiel-App veranschaulicht wichtige Webspeicherfeatures, einschließlich der Verwaltung von Cookies, SameSite-Cookies und partitionierten Cookies. Anzeigen

Siehe auch