Re: Cookies und Datenschutz


Subject: Re: Cookies und Datenschutz
From: Kristian Koehntopp (kris@koehntopp.de)
Date: Sun Nov 28 1999 - 10:57:00 CET


In schulung.lists.fitug-debate you write:
>Die cookies-Datei dient AFAIK dazu, die Informationen
>zwischen zwei Sessions zu erhalten. Solange Netscape läuft,
>werden die cookies genutzt.

So ist es.

Es gibt zwei Sorten von Cookies: Die mit einer Zeitangabe
(lifetime) und solche ohne. Cookies mit einer Zeitangabe haben
eine Lebensdauer bis zum Ablauf des Verfallsdatum. Sie werden in
der cookies.txt gespeichert, wenn der Browser beendet wird, um
dann beim naechsten Neustart erneut gelesen (und ggf. garbage
collected) zu werden. Cookies ohne Zeitangabe haben eine
Lebensdauer, die mit der Lebensdauer des Browserprozesses
identisch ist. Sie werden niemals in der cookies.txt gespeichert
und sie haben kein festes Ablaufdatum.

Wenn man die cookies.txt schreibschuetzt oder nach /dev/null
linked, verhindert man die Speicherung von Cookies mit
Lebensdauer. Man behaelt also Warenkorbfunktionalitaet, weil man
"Session-Cookies" weiter akzeptiert und zuruecksendet. Man
verliert aber Autologin-Cookies und GUID-Cookies.

Wenn man stattdessen Cookies im Browser abschaltet, verliert man
alle Cookie-Funktionalitaet. Warenkoerbe, die sich bei der
Korrelation von Seiten ausschliesslich auf Cookies verlassen,
funktionieren dann nicht mehr. Ausgefeiltere Systeme lassen sich
auch davon nicht beirren, sondern schalten transparent auf eine
Weitergabe der Session-ID in der URL um (PHPLIB, Microsoft ASP
mit Cookie Munger Extension, Apple/Next Webobjects und andere).
Damit hat man dann die Funktionalitaet von Session Cookies mit
anderen Mitteln, es sei denn, der Anwender bookmarked eine
solche Session-ID-haltige URL - in diesem Fall hat man eine
GUID.

Warum setzen Webanwendungen Session-IDs als Cookies oder Teile
der URL ein?

Sie wollen eine Folge von Zugriffe Deines Systems korrelieren,
also alle Zugriffe Deines Browsers von den Zugriffen aller
anderen Browser im gleichen Zeitraum unterscheiden koennen,
Deinem Browser also eine unverwechselbare Identitaet geben. Man
kann sich diese unverwechselbare Identitaet als Kennnummer
vorstellen, PHPLIB verwendet zum Beispiel einen MD5-Hash eines
Timestamps mit einem geheimen Saltwert. Ueber diese Kennung kann
die Anwendung dann einen Datensatz mit Variablen in einer
Datenbank referenzieren, etwa einen Warenkorb oder andere Daten,
die im Laufe einer Folge von Zugriffe akkumuliert worden sind.

     +-#19--+
    +-#18--+|
   +-#17--+<----- GET /shop/index.php3?ID=17 --- Browser
   | Cart |||
   | ||+
   | |+
   +------+

An diesem Szenario sind verschiedene Dinge wichtig, wenn man
lernen moechte, seine Privatsphaere zu schuetzen:

1. In dem Cookie selbst sind keine personenbezogenen Daten
   gespeichert. Es ist nicht der Cookie oder sein Wert, der
   gefaehrlich ist oder der geschuetzt werden muss. Der Cookie
   selbst enthaelt nur irgendeine zufaellige, aber eindeutige
   Nummer.

   Die personenbezogenen Daten sind in einer Datenbank auf
   dem Webserver gespeichert und verlassen dieses System auch
   niemals; jedenfalls nicht in Richtung Browser des Anwenders.
   Man selbst bekommst also auch niemals zu sehen, was genau
   in der Anwendung auf dem Webserver gespeichert ist, man kann
   diese Daten mit der ID nur referenzieren.

2. Cookies sind nur eine von mehreren Moeglichkeiten, Browser
   so zu brandmarken, dass eine Folge von Zugriffen
   unterscheidbar von allen anderen konkurrenten Folgen wird.
   Bekannt sind die folgenden drei Verfahren:

   a) Cookies
                         GET /shop/index.php3
                         Cookie: ID=17

   b) GET-Parameter in der URL

                         GET /shop/index.php3?ID=17

   c) PATH_INFO-Komponenten in der URL oder an anderen Stellen
      im URL-String (unter Einsatz von mod_rewrite)

                         GET /shop/index.php3/id/17

   PHPLIB und Microsoft ASP verwenden standardmaessig Verfahren
   a. PHPLIB kann automatisch auf Verfahren b umschalten, wenn
   der Anwender Cookies abgeschaltet hat. Microsoft ASP kann
   optional mit dem Microsoft Cookie Munger ausgeruestet werden
   und verhaelt sich dann wie c (glaube ich). Amazon verwendet
   Verfahren c.

   Cookies abzuschalten nuetzt also exakt nichts, wenn man
   die Erfassung von Sessiondaten verhindern moechte, da gute
   Installationen dann automatisch auf ein Fallback mit Hilfe
   eines anderen Verfahrens zurueck schaltet. Diese Verfahren
   sind fragiler als Cookies; Cookies sind genau fuer diese
   Aufgabe (eine Session-ID zur Referenzierung von Session-Datensaetzen
   in einer Datenbank transportieren) geschaffen worden.

   Schlechte Webshops funktionieren mit abgeschalteten Cookies
   gar nicht mehr. Man beraubt sich also im Namen einer nicht
   funktionierenden Methode zur Wahrung der eigenen Privacy der
   Moeglichkeiten, im Internet Einkaufen zu gehen oder
   komplexere Webanwendungen zu nutzen (es gibt schliesslich
   noch mehr sinnvolle Anwendungen fuer Session-Variablen als
   Warenkoerbe).
   
   Man propagiert auf diese Weise auch schlechte Webanwendungen,
   weil viele schlechte Installationen nun dazu uebergehen,
   Anwendungsdaten eben nicht in einer Datenbank lokal auf dem
   Server zu halten, sondern als Hidden-Variablen von Seite zu
   Seite mitzuschleppen - bei diesem Verfahren kreuzen interne
   State-Variablen einer Anwendung bei jedem Seitenwechsel die
   Trust-Boundary eines Systems und muessen entweder jedesmal
   neu validiert werden (macht niemand) oder werden zu einem
   Sicherheitsrisiko, weil sie benutzt werden koennen, um die
   Site aufzumachen. Das nuetzt dem Kunden, dessen
   Kreditkartennummer auf dem Server gespeichert ist, auch
   nicht.

3. Seine Privacy schuetzt man also nicht durch das Abschalten
   von Cookies: Zum einen koennen Gute wie Boese mit anderen
   Verfahren als Cookies weiter korrelieren, zum anderen macht
   man sich das Leben nur unnoetig unbequem.
   
   Seine Privacy schuetzt man, indem man mit den Leuten, die
   ungewollt Daten ueber einen Speichern nicht mehr redet. Das
   bedeutet, man installiert sich einen Junkbuster oder
   Webwasher als lokalen Proxy und erdet dort alle Zugriffe, die
   in Richtung von Systemen gehen, die man als Rogue erachtet,
   z.B. Doubleclick, Adfly, Flycast und wie sie alle heissen.
   (Blocken von allen Zugriffen auf *doubleclick* und so weiter)
   
   Man kann ausserdem sein System so konfigurieren, dass es
   Set-Cookies, die nicht an HTML-Dateien haengen, automatisch
   ausfiltert und dass es vorhandene Cookies ausfiltert, wenn
   diese an Requests von Bilddateien haengen. (Ausfiltern von
   Set-Cookie-Zeilen in allen Responses, wenn der Content-Type
   nicht text/html ist schaltet ankommende Cookies an
   GIF-Bildern und dergleichen aus; Ausfiltern von
   Cookie-Zeilen in Requests, wenn es sich um einen "GET /*gif"
   handelt, schaltet abgehende Cookies in GIF-Bildern und
   dergleichen aus).
   
   Man kann zusaetzlich verhindern, dass das eigene System
   Requests fuer Bilddateien absendet, wenn die letzten zwei
   Komponenten der Domain im GET-Request nicht mit den letzten
   zwei Komponenten der Domain des Referers uebereinstimmt.
   (Blocken von Requests fuer "GET /1x1.gif; Host:
   www27.doubleclick.com", wenn "Referer:
   http://www.kunde.de/artikel/art17.html").

   Die Grundidee ist es wie gesagt, nicht den Mechanismus
   auszuschalten, denn der ist _nicht_ boese und das ist auch
   nicht wirksam, sondern stattdessen korrekterweise und viel
   wirksaber die Abuser des Mechanismus zu schneiden.

4. Ausserdem kann bei der Gelegenheit auch gleich noch die
   Animation in animierten Gifs wegschneiden und alle remoten
   1x1 Placeholder-GIFs durch lokale welche ersetzen. :-)

Kristian (Autor PHPLIB; http://phplib.netuse.de, Anwender von
Junkbuster und auf der Suche nach einem besseren Tools als JB)



This archive was generated by hypermail 2b25 : Tue Dec 28 1999 - 12:40:42 CET