Drittanbieter-Cookies: Wie funktionieren sie und wie blockiert man sie?

Seit vielen Jahren schlagen Datenschützer Alarm wegen der Verwendung von Cookies zum Verfolgen, Erstellen von Profilen und Schalten personalisierter Werbung für Internetnutzer. Besonders heftig wurde die Diskussion über Cookies geführt, die für das seitenübergreifende Tracking verwendet werden. Bei diesen gibt eine Website Besucherdaten an in die Website integrierte Dienste Dritter weiter oder bietet sie diesen zumindest an.

Als Reaktion darauf haben einige der großen Webbrowser-Anbieter in den letzten zwei Jahren ihre Bemühungen verstärkt, verbesserte oder neue Optionen zum Blockieren von Cookies Dritter anzubieten. Im Jahr 2020 aktualisierte Apple die intelligente Tracking-Verhinderung in Safari und 2021 führte Mozilla die Total Cookie Protection in Firefox ein, um das Tracking durch Cookies von Drittanbietern zu unterbinden.

Google hat sogar versprochen, Cookies von Drittanbietern in Chrome zu deaktivieren, aber erst, wenn eine datenschutzfreundliche Alternative - die derzeit im Rahmen der Privacy Sandbox-Initiative erforscht wird - für Unternehmen entwickelt wurde, die Werbe- und Analysedienste benötigen.

All diese Bemühungen, Cookies von Drittanbietern zu blockieren, sin jedoch umsonst, wenn die Nutzer nicht die Einstellungen des Browsers ihrer Wahl zu überprüfen. Ein neu installierter Webbrowser blockiert Cookies von Drittanbietern möglicherweise nicht standardmäßig. Eine bemerkenswerte Ausnahme ist Firefox für den Desktop, bei dem der vollständige Cookie-Schutz seit Juni 2022 standardmäßig aktiviert ist.

Um die Problematik der Cookies besser zu verstehen, werden wir einen kurzen Blick auf die Header-Felder des Hypertext Transfer Protocol (HTTP) werfen und dann näher darauf eingehen, wie Cookies aussehen, wie sie von Webbrowsern gehandhabt werden und welche Auswirkungen ihre Verwendung auf Sicherheit und Datenschutz hat.

Warum verwenden Websites überhaupt Cookies?

Websites verwenden HTTP, um die von Besuchern angeforderten Webseiten bereitzustellen. Bei diesem Protokoll sendet ein Client - zum Beispiel ein Webbrowser wie Google Chrome - eine HTTP-Anfrage an einen Server, und der Server gibt eine HTTP-Antwort zurück. Beachten Sie, dass wir in diesem Artikel "HTTP" als Synonym für HTTP oder HTTPS verwenden.

HTTP ist ein zustandsloses Protokoll, d. h. ein Server kann die Anfrage verarbeiten, ohne von anderen Anfragen abhängig zu sein. Durch die Verwendung von Cookies können Server jedoch einen Zustand beibehalten - sie können mehrere Anfragen als von derselben Quelle stammend identifizieren, auch wenn die Seite neu geladen wird, man durch die einzelnen Seiten navigiert, der Browser neu gestartet wird und sogar Websites von Drittanbietern besucht werden.

Was sind HTTP-Header-Felder?

Ohne sich zu sehr in die Details von HTTP zu vertiefen, ist es hier am wichtigsten zu verstehen, dass eine HTTP-Anfrage Header-Felder enthält, die Informationen über die Anfrage verändern oder übermitteln. Betrachten wir die folgende Client-Anfrage:

Abbildung 1. Eine HTTP-Anfrage

Diese Anfrage hat zwei Header-Felder: User-Agent und Host.

Das Header-Feld User-Agent zeigt an, dass der Client, der die Anfrage stellt, Chrome Version 103 ist, der auf einem 64-Bit-Windows-10-Rechner läuft. Beachten Sie, dass User-Agent gefälscht werden kann. Das Host-Header-Feld gibt die Domäne und optional den Verbindungsport an, an die die Anfrage gerichtet ist, und ist für alle HTTP v1.1-Anfragen erforderlich; in diesem Fall ist die Domäne example.com.

Der Server example.com könnte eine Antwort auf die obige Anfrage senden, die wie folgt aussieht:

Abbildung 2. Eine HTTP-Antwort

Eine HTTP-Antwort enthält ebenfalls Header-Felder, die die Antwort verändern, und diese spezielle Antwort enthält sogar eine Nachricht. Der Grundgedanke ist auch hier, dass HTTP-Anfragen und -Antworten Header-Felder verwenden, die ihre Verarbeitung über die von ihnen gelieferten Informationen, zu denen auch Cookies gehören können, beeinflussen.

Was sind Cookies?

Ein Cookie ist ein Datenelement, das von einem Server an einen Client übermittelt wird, normalerweise über das Set-Cookie-Header-Feld in Form eines Name=Wert-Paares. Wiederholen wir die obige HTTP-Antwort, aber dieses Mal wird der Server versuchen, ein Cookie zu setzen.

Abbildung 3. Ein Server kann das Set-Cookie-Header-Feld verwenden, um Cookies an Clients zu senden

In diesem Beispiel-Cookie ist SessionID der Cookie-Name und 31d4d96e407aad42 ist der Cookie-Wert.

Wo werden Cookies gespeichert?

Wenn ein unter Windows laufender Google Chrome-Browser eine HTTP-Antwort mit Cookies empfängt, speichert er die Cookies auf der Festplatte in einer SQLite Version 3-Datenbank namens Cookies:

Abbildung 4. Pfad zur Chrome-Datenbank Cookies

Diese Datenbank enthält eine Tabelle mit der Bezeichnung cookies, in der der Cookie-Wert verschlüsselt und in einer Spalte mit der Bezeichnung encrypted_value gespeichert wird, zusammen mit den zugehörigen Metadaten, wie sie aus den anderen Spalten der Tabelle ersichtlich sind:

Abbildung 5. Die Spalten der cookies-Tabelle in der entsprechenden Chrome-Datenbank

Eine Teilzeile aus der cookies-Tabelle könnte wie folgt aussehen:

Abbildung 6. Eine Teilzeile in der cookies-Tabelle der entsprechenden Chrome-Datenbank

Tools, die versuchen, auf die Cookies-Datenbank zuzugreifen und Cookie-Werte zu entschlüsseln, können vom Echtzeit-Dateischutz der ESET-Produkte erkannt werden. Dieses auf GitHub verfügbare Python-Skript wird zum Beispiel als Python/PSW.Stealer.AD erkannt:

Abbildung 7. Der Echtzeit-Dateischutz der ESET-Produkte erkennt, dass Python/PSW.Stealer.AD versucht, Cookie-Werte zu entschlüsseln

Der Chrome-Browser ermöglicht es Ihnen jedoch, den entschlüsselten Cookie-Wert in Chrome DevTools anzuzeigen:

Abbildung 8. Das Cookies-Fenster in Chrome DevTools

Auch wenn es möglich ist, den entschlüsselten Cookie-Wert in Chrome DevTools anzuzeigen, macht der Wert wahrscheinlich wenig Sinn, da er entweder ein eindeutiger, zufälliger Wert ist (z. B. ein Sitzungsbezeichner) oder Daten enthält, die vom ausstellenden Server weiter verschlüsselt und signiert wurden und oft in einer "textsicheren" Weise wie base64 codiert sind.

Unabhängig von den im Cookie gespeicherten Daten darf die Länge des Name=Wert-Cookie-Paares vier Kilobytes nicht überschreiten.

Rückgabe von Cookies an den Server

Sobald ein Cookie gesetzt ist, können zukünftige Client-Anfragen an den Server, der das Cookie gesetzt hat, das Cookie in einem Cookie-Header-Feld enthalten. Wiederholen wir die obige HTTP-Anfrage, aber dieses Mal mit dem zuvor gesetzten Cookie:

Abbildung 9. Ein Client verwendet das Cookie-Header-Feld, um ein Cookie zurückzugeben

Einer der kritischen Punkte, die sich auf den Datenschutz und die Sicherheit im Internet auswirken, ist die Entscheidungslogik des Clients, ob Cookies in eine HTTP-Anfrage an den Ursprungsserver aufgenommen werden sollen. Dies hängt im Wesentlichen davon ab, ob die Anfrage in einem Erstanbieter-Kontext auf der Website, die das Cookie gesetzt hat, oder in einem Drittanbieter-Kontext auf einer anderen Website, die Ressourcen von der Website enthält, die das Cookie gesetzt hat, gestellt wird.

Als Nächstes wollen wir uns ansehen, wie sich die Sicherheits- und Datenschutzfunktionen von Cookies auf die Entscheidung des Clients auswirken, Cookies zurückzugeben.

Cookie-Sicherheit

Angenommen, ich melde mich bei meinem Konto auf einer Website an. Ich erwarte, dass der Server sich merkt, dass ich angemeldet bin. Deshalb sendet der Server ein Cookie, nachdem ich mich authentifiziert habe. Solange der Client dieses Cookie bei nachfolgenden Anfragen an den Server zurückschickt, weiß der Server, dass ich angemeldet bin, und ich muss mich nicht bei jeder Anfrage neu authentifizieren.

Stellen Sie sich nun vor, dass ein Angreifer dieses Cookie irgendwie stiehlt, vielleicht durch per E-Mail verbreitete Malware. Der Besitz dieses gestohlenen Cookies ist fast so gut wie der Besitz meiner Authentifizierungsdaten, da der Server die Verwendung dieses Cookies mit meiner Authentifizierung in Verbindung bringt.

Um die Gefahren eines solchen Cookie-Diebstahls zu mindern, kann der Server einige Maßnahmen ergreifen.

Erstens kann dieses spezielle Cookie so eingestellt werden, dass es nach einer kurzen Zeit der Inaktivität abläuft. Nach Ablauf dieses Zeitraums ist ein gestohlenes Cookie für einen Dieb nutzlos, da das Konto effektiv abgemeldet wird.

Zweitens kann der Server verlangen, dass kritische Aktionen, wie das Zurücksetzen des Kontopassworts oder z. B. die Überweisung eines größeren Betrags in einer Bankanwendung, mit dem aktuellen Passwort oder einem anderen Mechanismus wie einem Verifizierungscode bestätigt werden. Ein Cookie-Dieb sollte nicht in der Lage sein, mein Passwort zurückzusetzen oder mein Bankkonto zu leeren, nur weil er das Cookie hat.

Schließlich kann der Server dieses Cookie mit so vielen Attributen für eine strengere Sicherheit versehen, wie es für den Zweck des Cookies angemessen ist. Dies bedeutet die Verwendung der folgenden Attribute:

• Secure, das die Clients anweist, das Cookie nicht in unverschlüsselte HTTP-Anfragen einzubinden [dies ist eine Abschwächung gegen Adversary-in-the-Middle-Angriffe (AitM)];
• HttpOnly, das Clients anweist, den Zugriff von Nicht-HTTP-APIs wie JavaScript auf das Cookie zu verhindern [dies ist eine Maßnahme gegen Cross-Site-Scripting-Angriffe (XSS)];
• SameSite=Strict, was die Clients anweist, das Cookie nur in Anfragen an Domains einzubinden, die mit der aktuellen Website übereinstimmen, die in der Adressleiste des Browsers angezeigt wird [dies ist eine Maßnahme gegen Cross-Site Request Forgery (CSRF)-Angriffe]; und
• Path=/, was die Clients anweist, das Cookie in Anfragen an einen gewählten Pfad der Domäne aufzunehmen. In Kombination mit dem nächsten Punkt in dieser Liste kann das Cookie als für die Domäne "gesperrt" betrachtet werden;
• aber nicht Domain, um zu verhindern, dass das Cookie in Anfragen an Subdomains des Hosts, der das Cookie gesetzt hat, aufgenommen wird. Zum Beispiel sollte ein Cookie, das von com gesetzt wurde, nicht an accounts.google.com gesendet werden.

Der Versuch, einen solches verschärftes Cookie zu setzen, würde wie folgt aussehen:

Set-Cookie: SessionID=31d4d96e407aad42; Secure; HttpOnly; SameSite=Strict; Path=/

Hier sind die Attribute, die auf das erste name=value-Paar folgen, ebenfalls Teil des Cookies.

Die Ergreifung weiterer Maßnahmen zum Schutz einer Website vor AitM-, XSS- und CSRF-Angriffen trägt ebenfalls zur Sicherheit von Cookies und der von ihnen bereitgestellten Dienste bei.

Natürlich können Cookies nicht nur für angemeldete Benutzer verwendet werden. Sie können auch verwendet werden, um Artikel in einem Einkaufswagen zu speichern, sich an Benutzereinstellungen zu erinnern und das Benutzerverhalten zu verfolgen.

Erstanbieter-Cookies vs. Drittanbieter-Cookies

Das Tracking über Cookies kann sowohl im Zusammenhang mit Erstanbieter- als auch mit Drittanbieter-Cookies erfolgen. Heutzutage ist das Tracking über First-Party-Cookies eine Selbstverständlichkeit, wenn es gemäß den Datenschutzgesetzen offengelegt wird, und man kann kaum etwas dagegen tun. Unter Umständen wird vielleicht die Website nicht richtig dargstellt oder funktioniert nicht richtig wenn Sie alle Cookies blockieren oder sie durch Surfen im privaten oder Inkognito-Modus einschränken. So erscheint man bei jedem Besuch der Website als neuer Besucher, wenn  man ein neues Fenster oder eine neue Registerkarte geöffnet und eine neue Browsersitzung begonnen hat.

Aber was genau ist ein Erstanbieter-Cookie? Nehmen wir Google als Beispiel. Wenn Sie https://google.com in Ihrem Webbrowser öffnen, werden alle Cookies, die vom google.com-Server gesetzt werden und in Ihren Client-Anfragen (Browser) an google.com enthalten sind, als Erstanbieter-Cookies betrachtet. Eine einfache Möglichkeit, dies zu überprüfen, besteht darin, nach Cookies mit dem Domain-Attributwert google.com zu suchen, da diese mit der Domain übereinstimmen, die in der Adressleiste des Browsers angezeigt wird.

Chrome DevTools verfügt über ein Filter-Feld zum schnelleren Auffinden von Anfragen anhand ihrer Domäneneigenschaft und einen Cookies-Tab zum Anzeigen der mit jeder Anfrage gesendeten Cookies:

Abbildung 10. An google.com zurückgegebene Erstanbieter-Cookies

Und was ist ein Drittanbieter-Cookie? Wenn Sie eine Nicht-Google-Website wie welivesecurity.com besuchen, die Anfragen an google.com auslöst - vielleicht enthält die Webseite ein eingebettetes YouTube-Video, das ein auf google.com gehostetes Skript lädt - werden die in diesen Anfragen enthaltenen Cookies als Drittanbieter-Cookies betrachtet. Eine einfache Möglichkeit, dies zu überprüfen, ist die Suche nach Cookies mit dem Domain-Attributwert google.com, da diese nicht mit der in der Adressleiste des Browsers angezeigten Domain übereinstimmen:

Abbildung 11. An google.com zurückgegebene Cookies von Drittanbietern

Beachten Sie, wie wenige Cookies an google.com zurückgegeben werden, wenn Sie diesen WeLiveSecurity-Artikel besuchen, im Vergleich zu der Vielzahl von Cookies, die zurückgegeben werden, wenn Sie direkt auf google.com gehen. Dies ist auf das SameSite-Attribut des Cookies zurückzuführen. Im Kontext von Drittanbietern können nur Cookies zurückgegeben werden, die sowohl mit dem Attribut SameSite=None als auch mit dem Attribut Secure gesetzt wurden.

Aus diesem Grund sind Unternehmen, die sich mit Analysen, Werbung und Personalisierung beschäftigen, stark an SameSite=None; Secure Cookies interessiert. Das NID-Cookie von Google zum Beispiel ist ein super Tracker, der folgendes kann:

• Einstellungen wie die bevorzugte Sprache, die Anzahl der Ergebnisse, die auf einer Suchergebnisseite angezeigt werden sollen, und ob der SafeSearch-Filter von Google aktiviert ist, speichern
• Analysen zur Google-Suche sammeln
• gezielte Google-Anzeigen in Google-Diensten für nicht angemeldete Nutzer anzeigen
• personalisierte Autovervollständigung bei der Eingabe von Suchbegriffen in der Google-Suche aktivieren

Das NID-Cookie könnte unbegrenzt bestehen bleiben. Eine beängstigende Vorstellung - es sei denn, Sie löschen es manuell, da es sechs Monate nach Ihrer letzten Nutzung eines Google-Dienstes abläuft, z. B. jedes Mal, wenn Sie sich bei Ihrem Konto anmelden oder abmelden.

Login Fingerprinting

Um eine bessere Vorstellung von der Tracking-Fähigkeit von Drittanbieter-Cookies zu bekommen, können Sie eine Website besuchen, die ein Stück HTML- und JavaScript-Code verwendet (Hut ab vor Robin Linus), um eine speziell gestaltete Anfrage an den Google-Login-Dienst zu stellen, nachdem die Seite geladen wurde.

Wenn Sie auf die Schaltfläche "Run" unten klicken, wird eine von zwei Aktionen ausgeführt. Wenn Cookies von Drittanbietern in dieser Browsersitzung aktiviert sind, zeigt der Code das Google-Favicon unter der Schaltfläche an und öffnet ein Warnfenster mit der Meldung 'You are logged into Google in this browser' ("Sie sind in diesem Browser bei Google angemeldet"). Wenn jedoch Cookies von Drittanbietern in diesem Browser blockiert sind, zeigt der Code das Favicon unter der Schaltfläche nicht an und öffnet ein Warnfenster mit der Meldung 'I don’t know if you are logged into Google' ("Ich weiß nicht, ob Sie bei Google angemeldet sind"). Sie können beide Aktionen testen, indem Sie diese Seite zwischen den Durchläufen aktualisieren.

<img onload="alert('You are logged into Google in this browser')"
onerror="alert('I don’t know if you are logged into Google')"
src="https://accounts.google.com/ServiceLogin?continue=https%3A%2F%2Fwww.google.com%2Ffavicon.ico">

Run

Abbildung 12. Durch Klicken auf "Run" wird geprüft, ob Sie in dieser Browsersitzung bei Google angemeldet sind

Google verwendet ein Cookie namens __Host-3PLSID, das in Anfragen aus dem Kontext eines Drittanbieters enthalten sein kann. Wenn Sie angemeldet sind, wird dieses Cookie in die Anfrage aufgenommen, wodurch die Anfrage erfolgreich ist und Ihr Anmeldestatus an die Website des Drittanbieters weitergegeben wird.

Das gleiche Problem gilt für PayPal, obwohl mehrere Durchläufe dazu führen können, dass PayPal die Lösung eines CAPTCHA verlangt, das dann das Login-Fingerprinting verhindert:

<img onload="alert('You are logged into PayPal in this browser')"
onerror="alert('I don’t know if you are logged into PayPal')"
src="https://www.paypal.com/signin?returnUri=https%3A%2F%2Ft.paypal.com%2Fts?v=1.6.8">

Run

Abbildung 13. Durch Klicken auf Run wird geprüft, ob Sie in dieser Browsersitzung bei PayPal angemeldet sind

Fast alle Cookies, die paypal.com setzt, können in einem Drittkontext zurückgegeben werden. PayPal scheint mindestens zwei Cookies namens id_token und HaC80bwXscjqZ7KM6VOxULOB534 zu verwenden, um eingeloggte Benutzer zu identifizieren.

Blockieren von Drittanbieter-Cookies

Login-Fingerprinting funktioniert nicht auf allen Websites, da es eine Schwachstelle ausnutzt (auch wenn sich nicht jeder Dienstanbieter darüber Gedanken macht), die darin besteht, wie der Server seinen Login-Mechanismus und seine Handhabung von Weiterleitungen implementiert hat. Um zu verhindern, dass Sie auf verschiedenen Websites verfolgt werden und Ihr Anmeldestatus möglicherweise bekannt wird, stellen Sie sicher, dass die Einstellungen Ihres Browsers zum Blockieren von Cookies Dritter aktiviert sind.

Die folgende Liste beschreibt, wo Sie die Einstellungen für Cookies von Drittanbietern in den gängigsten Webbrowsern finden.

Firefox

Wie wir eingangs erwähnt haben, ist die Total Cookie Protection in Firefox für den Desktop seit Juni 2022 standardmäßig aktiviert. Neben dem Blogpost, auf den wir gerade verlinkt haben, bietet dieser Support-Artikel eine ausführlichere technische Diskussion über diese Funktion, einschließlich der Fehlerbehebung bei Websites, die bei aktivierter Funktion nicht richtig funktionieren. Versierte Benutzer möchten vielleicht die Standardeinstellungen anpassen, die Sie hier finden:

Abbildung 14. Anpassung der Firefox-Einstellungen für einen besseren Schutz vor Tracking (engl.)

Chrome

Der Chrome-Browser bietet die Einstellungen für Cookies unter "Datenschutz und Sicherheit":

Figure 15. The "Block third-party cookies" setting in Chrome (engl.)

Wenn Sie die Option "Cookies von Drittanbietern blockieren" aktiviert haben, werden alle Cookies von Drittanbietern blockiert - sie werden weder an den Server zurückgeschickt, noch können sie auf dem Client gesetzt werden:

Abbildung 16. Chrome blockiert Cookies von Drittanbietern

Edge

Für den Microsoft Edge-Browser folgen Sie den Zahlen in der Abbildung unten, um Cookies von Drittanbietern zu blockieren:

Abbildung 17. Die Einstellung "Cookies von Drittanbietern blockieren" in Edge (engl.)

Aktivieren Sie in den Einstellungen von Safari auf iOS die Option "Cross-Sitetracking verhindern":

Safari on iOS

Abbildung 18. Die Einstellung "Cross-Sitetracking verhindern" in Safari auf iOS (engl.)

Drittanbieter-Browser unter iOS

iPhones verfügen über die Einstellung "Cross-Sitetracking erlauben", die für jeden Browser eines Drittanbieters über die App "Einstellungen" verfügbar ist. Überprüfen Sie also nicht nur die Cookie-Einstellungen der einzelnen Browser-Apps, sondern stellen Sie auch sicher, dass diese Einstellung nicht aktiviert ist:

Abbildung 19. Die Einstellung "Cross-Sitetracking erlauben" in Chrome auf iOS (engl.)

Fazit: Vorhersage des Todes von Drittanbieter-Tracking Cookies

Die Schlinge um die Cookies von Drittanbietern zum Tracking zieht sich aus mindestens drei Gründen zu. Erstens durch Nutzer, die auf ihren Geräten und Apps die Methoden zur Blockierung von Cookies aktivieren. Zweitens von Webbrowser-Anbietern, die ihre Standard-Browsereinstellungen verstärken, um das Tracking einzuschränken. Drittens von Webentwicklern, die alternative Speichermechanismen zur Handhabung von seitenübergreifenden Ressourcen verwenden.

Angesichts dieser zunehmenden Bemühungen, das Online-Tracking zu verhindern, steht das langfristige Überleben von Cross-Site-Tracking-Cookies auf wackligen Beinen, und wir können ihr Ende in nicht allzu ferner Zukunft vorhersagen.

Haben Sie Fragen und Anregungen zu diesem, anderen oder zukünftigen Themen, die Sie gern betrachtet sehen wollen? Dann nutzen Sie gern die Kommentarfunktion unter diesem Artikel oder nutzen unser Kontaktformular!